Re: [REVIEW] domain-mapper import speedup patch ...

On 21/12/12 17:55, Michael Meeks wrote:
>       There are probably better ways to do this :-) clearly it would be nice
> to manage layered SfxItemSets via UNO in an even more performant and
> elegant way that doesn't rely on great big uno PropertyValue sequences
> getting sent repeatedly and so on. Anyhow the attached gives a
> reasonable win on RTF import: 25% faster or so. It's hard to see how it
> could make things much perform worse.

wow - i've always suspected that it's unnecessarily slow to set these
items in the model one at a time, when there is a InsertItemSet
available, but 25% faster import with this single change is impressive.

there may be more places where a similar approach could be applicable,
both in API implementations in sw and in writerfilter/xmloff import
code, e.g. see cc99bb9f383a65912d004e227a5b6a88b401bbba which was purely
result of me debugging some crash and wondering why a certain insert
method in sw core is called so often (in that case sw API impl. actually
did the right thing).

> It has a FIXME - I'm unclear
> exactly what's going on there. Clearly I'm wandering at the edge of my
> competence wrt. the writer bits here, so help/encouragement appreciated.

> +            // FIXME: unclear that we need to do this really ...
> +            if (!rCursorMap.getByName( rCharacterAndParagraphProperties[nProp].Name ))
>              {
> -                sMessage = rIllegal.Message;
>                  bIllegalException = true;

i suppose this exception would be thrown by
SwUnoCursorHelper::SetPropertyValues now anyway... which is actually a
problem because in that case
  m_pImpl->m_pDoc->GetIDocumentUndoRedo().EndUndo(UNDO_INSERT, NULL);
won't be executed and we get a confused UNDO stack in writer...

i guess it's best to move the Start/EndUndo into
SwUnoCursorHelper::SetPropertyValues to fix that (can't be omitted
entirely since it's possible that multiple different Undo objects are
created).