[dojo-contributors] Lazy Parsing and fast widget creation

Ilia Kantor ilia at dojotoolkit.org
Tue Jun 27 02:51:23 EDT 2006

-) I briefly examined the idea and couldn't find where lies a real win. It
introduces additional complexity, but how to get performance out of it?
Amount of rendering is same for both cases. We have to store data somewhere
anyway, what's the performance diff if it is a widget itself or another
place ?

Maybe you could suggest the code for TreeV3 that implements such approach
and show the performance boost ?



From: dojo-contributors-bounces at dojotoolkit.org
[mailto:dojo-contributors-bounces at dojotoolkit.org] On Behalf Of Jesse
Sent: Tuesday, June 27, 2006 5:09 AM
To: dojo dev.
Subject: Re: [dojo-contributors] Lazy Parsing and fast widget creation


Forgive me for interjecting as I've only casually been following what you
have been doing as anything involving performance always excites me .. ;)
This also isn't meant to detract from what you are doing, just very high
level observations of the process in general. 

-) The first and easiest thing to look at is why are so many widgets being
created ? In traditional gui development it is common to have only a small
set of objects responsible for rendering when dealing with large data
sets..This allows them to be used as a sort of "stamp" without literally
creating a 1-to-1 map between data and UI object. I think any toolkit would
start to choke after too much of this regardless of whether it's an
interpreted language or closer to the core. Maybe another approach would be
to start thinking about working on some sort of data manager sort of utility
to allow seperation of UI and data? 

-) From the very very brief reading I've done in the mozilla codebase at
least (please keep your BS radar settings on high as a lot of this is either
inferred or only dimly remembered from method comments / similar patterns of
logic) while it may be called the "DOM" and have all of the programmatic
typical dom methods it is nothing like the non-gui DOM versions people use
to parse xml under normal conditions..(In fact I think the typical case
still applies as they are using native parsers anyways, but the resultant
structure isn't a cost-free thing to muck around with ). 

You could try segmenting off your own section of code and try a different
approach to widget parsing (going even farther into territory where I don't
know what I'm talking about, at least with browser stuff) of content in
general. I don't remember what the current parser does, but if you did a
sort of two phase parse of these widgets it may help as well. The first
phase for doing all of the creation/manipulation of basic dom structure, and
the second for doing anything involving style/looking up other
widgets/etc...The overall goal would be to try and save up all of the
expensive operations that require lots of cross checks and general browser
quietness for last when everything is already hopefully fairly quiet. If
things go well and you are able to definitively determine what is/isn't
expensive breaking them up like this may yield great results. 

The dom.style references I was making in a previous email were from my
understanding of how the values are read. (which may be wrong) Something
along the lines of style size/etc not being calculated until someone asks
for it specifically was what I remembered. This should then be cached for
future reads, unless someone does something to change the state of the dom
in some way. (this state changing logic is probably more advanced than
forcing re-calculations on ~any~ change, but the basic idea is probably
there?...) This makes sense, as even underneath the covers the normal gui
toolkits that we all know and love (ok at least maybe gtk / qt / windows for
me, though I can't say I'm a very big fan of windows or gtk...) would still
not make calculating the most efficient thing to do. It's still better than
doing it during rendering as that would add all kinds of overhead that may
not even be needed in a lot of instances. 

-) Try the widget parse / xml idea in combination with the data manager
using JSON structures instead? If it even makes a difference, you could try
creating JSON data structures that have function hooks embedded within them
to automatically add/do whatever needs to be done with the data while it's
being eval'ed instead of having it happen again on a second iteration of the
data after it's been parsed? I don't know if they xsl implementations
available via javascript offer any sort of callback hooks but if they did
that would be awesome. 

Those are my completely made up ideas. Can't say I've tried any of them in
javascript code at all, but definitely have in a few languages(esp the one
mozilla is implemented in)- all with more or less the same performant
results. It's a crap shoot but thought I'd share my disjointed (probably
unhelpful) thoughts anyways.. 

On 6/26/06, Ilia Kantor <ilia at dojotoolkit.org> wrote:

I'm optimizing the tree for performance now. The problem is that markup
creation is very slow.


Everything is overridden for speed, but I still measure 0.7 sec for 100
nodes. That's far too slow.


Widget creation is most time-consuming part, but parsing is also an
expensive and memory-hungry operation.

I think we need a way to stop-resume parsing of DOM (xml/Parse.js).


E.g for the tree we specify

<dojo:Tree lazyParse="true">

            <dojo:TreeNode> node level 1

                        <dojo:TreeNode> node level 2

                                    <dojo:TreeNode> node level 3



When a person clicks expand node1 then widgets runs parsing of one more
level and new widgets are created.


-          only one more level to process, not all

-          widget should know (or be able to know) if it has subwidgets (to
show +- expand labels).

We can do that in markup with explicit isFolder=true attribute, is there
another way ?



Any widget that puts lots of information in markup and allows lazy parsing
will benefit from this feature.


dojo-contributors mailing list
dojo-contributors at dojotoolkit.org 

Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060627/90a60d6b/attachment.htm 

More information about the dojo-contributors mailing list