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

List:       koffice-devel
Subject:    Re: design discusion: using QtXmlStreamReader instead of KoXmlReader
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2010-08-10 15:14:25
Message-ID: 201008101714.26294.t.zachmann () zagge ! de
[Download RAW message or body]

On Tuesday 10 August 2010 14:28:47 Jos van den Oever wrote:
> On Tuesday, August 10, 2010 17:22:04 pm Björn Breitmeyer wrote:
> >  From my experience with QXmlStreamReader you have one fundamental
> > 
> > difference in comparison to KoXmlReader. QXmlStreamReader is really
> > a stream, this means you cant go back. This leads to the problem
> > that any function can disrupt the whole loading process if it reads
> > too much or not enough data.

We often go back and read data a second time .e.g. when one shape cannot load 
the item and the next shape is tried to load it. 

> This is exactly the reason I'm not sure the transition is feasible.  What
> is feasible, however, is to replace QXmlReader with QXmlStreamReader. That
> should already give a nice speedup if the Qt API docs are to be believed.
> I wonder why QDomDocument is not using it though ...

QDomDocument was used before KoXmlReader was created. It resulted in very big 
memory usage when loading documents. Using mutiples 100Mb where very common. 
Therefore the KoXmlReader was invented to use less memory during parsing of 
the document.

> If we encounter a place where the loader has to fall back to XML elements
> that were present in a previous part of the stream, then it should now use
> the parsed members that were created from the corresponding XML. If this
> is feasible, we will see. We can always keep using KoXmlElement if there
> is no other option.

Using a QXmlStreamReader instead of QXmlReader inside KoXmlElement might work. 
No idea how easy it is to implement. Using QXmlStreamReader instead of 
KoXmlElement however will not work without major changes to the full source 
code. 
Actually I'm not sure that QXmlStreamReader is faster then the sax parser used 
at the moment even if the documentation says so. It also says it might be 
faster then using a QDomDocument and I think we agree that using a sax parser 
instead of a QDomDocument is faster.

Thorsten
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

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