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

List:       koffice-devel
Subject:    Re: Faster saving
From:       Thomas Zander <zander () kde ! org>
Date:       2004-04-13 16:54:25
Message-ID: 200404131854.28486.zander () kde ! org
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Slightly off-topic; but interresting are the results that I read about 
recently of a new IO system approach in an API I use.
The old ones used a streams based approach; where each byte that comes in 
is encoded as soon as it comes in.
The new style has a Buffer object which can contain any number of 
characters; and only when thats full is when all the text is converted 
(like from QChar or char* to utf-8).
Unlike you expect the speed gains were amazing; it seems that staying in 
the processors cache while doing something as trivial as utf-8 encoding is 
quite lucrative.

In light of that the approach Werner had in mind I found this bit info good 
to share.
I can imagine having a writer that has a QDom API and when its internal 
buffer is full; it converts the stuff into utf-8 and then streams it to 
the storage device.

Cheers!

On Tuesday 13 April 2004 16:45, David Faure wrote:
> On Sunday 15 February 2004 23:57, David Faure wrote:
> > On Sunday 15 February 2004 16:56, Nicolas Goutte 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?
> I remember that we sort of dropped it at the time because the old format
> required to be able to go back to the beginning of the xml doc and add
> stuff there. But I think we don't need this anymore, with the OASIS
> format.

- -- 
Thomas Zander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAfBtDCojCW6H2z/QRAqKwAJ4uHzk4H3/32VMYqpKJ2SMF2Gx9KgCfQ0bZ
blUUI1asVp/8G5xrbSPtUa8=
=y55N
-----END PGP SIGNATURE-----
_______________________________________________
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]