[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:25
Message-ID: 200404132157.27860.nicolasg () snafu ! de
[Download RAW message or body]

On Tuesday 13 April 2004 18:54, Thomas Zander wrote:
> -----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.

Sorry, but where does it differ from David's KBufferedIODevice solution?
(And the gain, in this case, is mainly how Qt is programmed and therefore can 
change for Qt4.)

>
> 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.

But this as little sence. If you use QDom, it is for the flexibility to add 
tags where and when you want. Otherwise, you can well go away from the QDom 
idea and write directly the tags.

>
> Cheers!

Have a nice day!

>
> 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

_______________________________________________
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]