[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Faster saving
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2004-04-13 20:10:54
Message-ID: 200404132207.17690.nicolasg () snafu ! de
[Download RAW message or body]

On Tuesday 13 April 2004 19:26, Werner Trobin wrote:
(...)
> > > > > It has taken (rounded values):
> > > > > QCString: 19s
> > > > > QTextStream: 55s
> > > > > KBufferedIODevice( 8KB ): 41s
> > > > > KBufferedIODevice( 64KB ): 35s
> > > > > KBufferedIODevice( 128KB ): 34s
> > > > >
> > > > > So something is still worng.
> > > >
> > > > valgrind-calltree/KCachegrind explains it. It's the unicode->utf8
> > > > conversion that takes too much time with the QTextStream solutions,
> > > > because the codec is triggered for every character - whereas with the
> > > > QCString solution it's only triggered once, for the whole of the
> > > > data.
> > > >
> > > > I also agree with waiting for Qt 4, we'll optimize then, depending on
> > > > how it does it.
> > >
> > > One more thing on this thread: it's about time we start implementing
> > > saving in the OASIS format. Since you wrote most of the current code
> > > relating to this (oowriterexport.*), do you think we should use the
> > > QDomDocument solution or your "direct writing of text into the ZIP
> > > device" solution (zipWriteData), i.e. writing litteral XML directly?
> > >
> > > Doesn't the latter lead to syntax errors too often? (and encoding
> > > errors?) It has the advantage that when writing out utf8 or simple
> > > latin1 stuff (tags/attributes) no char*->QString->char* conversion is
> > > needed, though (unlike currently).
> > >
> > > Hmm, Werner wrote another solution, with a class that has an API almost
> > > like QDom, but writes out the stuff along the way instead of all at
> > > once, IIRC. (This has the advantage that it requires much less memory
> > > than the huge-QDomDocument approach). Werner, what's the status on
> > > this?
>
(...)
>
> What about having "templates" of paragraphs in memory, already in string
> form and encoded. When you have to write out another paragraph you just
> (deep) copy that full string and fill out the attributes. E.g.
>

> <paragraph><blah width="        "/><foo name="              ">bleh</foo>

> <layout>
> <blubb font="      "/>...
> </layout>

No, in OO, something like layout is defined by an automatical style, rather at 
the start of content.xml. So of course you have little to add at the level of 
the paragraph, but you have much to add where the automatical style are 
defined.

>
> In order to avoid excessive search&replace copying you have to add some
> spaces for the attribute values (for most of them we know the maximum
> length). Then you also know the index of the attributes and can replace on
> the fly. If you have tags of variable length (e.g. font name) you can split
> the full string in several pieces and process them sequentially.

I do not understand what that is supposed to bring.

The definition of an automatical style is of varaible length: it can be as 
short as to tell "same as this other style" or as long as to list all 
possible OO properties.

>
> This would probably pay off for tags which are used really really often. If
> you implement the fake-dom hierarchy you could even hide all those crude
> hacks behind a sane API by providing a ParagraphElement or so, where you
> just set the attributes via public setFoo() calls.
>
> That said, I unfortunately don't have the time to give it a try for the
> next few months :-(
>
> Ciao,
> Werner

Have a nice day!

>
(...)

_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]