Re: Why does Barracuda choose the way to parse the whole page (*ML) to a doc?

On Monday 17 March 2003 06:31, Xue-Feng Yang wrote:
[ ... snip ... ]
> I think you misunderstand here. It is true that you
> can modify LazyDOM without openning other nodes, but
> when you get the updated page from LazyDOM, you must
> parse all of the nodes. That is painful.

What do you mean by "updated page"? Sending out a page to the browser, or 
re-parsing a changed page from the source *ML?

If you mean the first case, that's exactly what LazyDOM is optimized for - and 
it certainly doesn't parse anything in this case. It simply walks over the 
(unexpanded) DOM tree and dumps the nodes to the output stream. For almost 
all nodes (i.e., for all nodes that have not been modified dynamically), this 
is as simple as a single call to PrintWriter.print() to dump the preformatted 
node contents. At the moment, XMLC has to walk the entire DOM to do this 
(I've planned to change this in the next major release so that a complete, 
unexpanded subtree can be output with a single print()), but performance 
measurements indicate that this treewalk is pretty fast, even on big DOM 
trees. Sure, it's O(n) (n = #of nodes in the tree), but the actual factors 
are small enough that I don't worry about performance for trees with only a 
couple of thousand nodes. 

The real bottleneck is converting the internal unicode based representation of 
the DOM content into the charset desired by the browser - especially 
converting characters to *ML escape sequences asw necessary, because this 
means that each and every character has to be tested individually. And that 
bottleneck is nicely omitted for the average case (i.e. for output to the 
charset that is requested most often) by keeping the node contents around as 
pre-formatted text for this charset.

If you mean reparsing from a changed document - that's not really an issue, 
because reparsing occurs very rarely in the environments that XMLC is 
designed for (think about a typical website with 10000 page hits a day, and a 
page with changes to the static content once a week). 

Anyway, reparsing isn't that slow either - I've yet to find a case where it 
causes a noticeable delay. Sure, the delay is measurable, but it is (even for 
big pages and on low- to mid-range hardware) well below half a second, and 
that's (at least in my opinion) tolerable in a web environment.

And if you're concerned about memory consumption - LazyDOM is optimized for 
that as well. The "on-disk" state of a document is shared among all document 
instances. Nodes are only expanded when they are accessed through the 
standard DOM api (that's why it's called the "lazy" DOM). This means that in 
your example you only have one single instance of the big, unchanged bulk of 
the document in memory, regardless of how many dynamic instances you've got 
sitting around.

Best regards,

Richard

-- 
Richard Kunze 

[ t]ivano Software, Bahnhofstr. 18, 63263 Neu-Isenburg
Tel.: +49 6102 80 99 07 - 0, Fax.: +49 6102 80 99 07 - 1
http://www.tivano.de, [email protected]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQA+dZom86Aqb3OZfF4RApjrAJ4ky1OUB2zDFDLTlqL05vSlEDpF5ACfUc5r
/omFyPBfQfuW24e17XfkvdM=
=6OCC
-----END PGP SIGNATURE-----