[dojo-contributors] Lazy Parsing and fast widget creation

Jesse Kuhnert jkuhnert at gmail.com
Tue Jun 27 08:08:52 EDT 2006


Not nearly as functional client-side wise, but my own tree implementation
has been used to display roughly 100k records or so...Paging implementations
were used for most of the data but you get my point..

http://opencomponentry.com:8080/tacos/app?page=ajax%2FTreeExample&service=page

On 6/27/06, Ilia Kantor <ilia at dojotoolkit.org> wrote:
>
>  -) 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 Kuhnert
> *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
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>
> _______________________________________________
> dojo-contributors mailing list
> dojo-contributors at dojotoolkit.org
> http://dojotoolkit.org/mailman/listinfo/dojo-contributors
>
>
>


-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20060627/2c6a481e/attachment.htm 


More information about the dojo-contributors mailing list