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

List:       koffice-devel
Subject:    Re: plan for lightweight DOM implementation
From:       Tomas Mecir <mecirt () gmail ! com>
Date:       2005-10-30 15:57:11
Message-ID: 492258b10510300757i4e5b1e73g374989900f41a7fa () mail ! gmail ! com
[Download RAW message or body]

On 10/30/05, Ariya Hidayat <ariya@kde.org> wrote:
> I'd like to give a try to implement alternative DOM implementation
> which does not consume as much memory as typical QDom classes. My goal
> is to have counterparts to important QDom stuff (like QDomDocument,
> QDomNode, QDomElement) and retain the API so that current document
> loading code can only be slightly modified. This is in constrast e.g.
> if we go full the SAX-way and need to rewrite almost everyting.
>
> The idea is as follows. Each node does not necessarily load the
> attributes and its children at once, but rather only on-demand. Upon
> loading the main document, only information about the first level
> nodes/elements (which are children of the document) are loaded. For
> each node, the positions in the content corresponding the node data
> are saved. When this node is accessed, then it will "rewind" again the
> content to the appropriate position, reparse the data, and again
> capture only its direct children nodes.
>
> Node can also have unload() method which explicitly purged its data
> from memory. This is useful when the program knows it will not use the
> node anymore. Example: when KSpread starts to parse the second sheet,
> the first <table> element is not useful and can be thrown away.
>
> I expect a performance degradation since parsing needs to be performed
> many times. However, I estimate that memory requirement will be much
> less. My guess is that this is worth doing it.
>
> So I'm starting to work on this, and comments are warmly appreciated.

I think it would be nice to start an alternate project too, where we'd
investigate the current loading code to see how much would need to be
changed. We -think- that it would be a lot ... but is it really so?
Half the stuff could remain nearly the same in my opinion, because
half the classes are loaded from a very small chunk of XML. I may try
to start the investigation at some point, but first I'll need to have
a closer look at how SAX exactly works.

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