[Kss-devel] getHtmlIdSelector and cssQuery speed issues
Balazs Ree
ree at ree.hu
Thu Apr 5 06:36:30 CEST 2007
On Mon, 02 Apr 2007 11:24:15 +0200 Hedley Roos:
> I have a script which does ten calls to getHtmlIdSelector and then
> subsequent ksscore.replace(Inner)HTML's.
>
> According to firebug the cssQuery function gets called 197764 times. It
> is extremely slow. When I modify the script to only do two
> getHtmlIdSelector's cssQuery gets called 23858 times. The rest of the
> javascript functions use less than 2% of the execution time.
That's a little bit too much and it needs an investigation. It should not
be called that many times. (maybe, cssQuery is recursive? Or is there a
chance your insertions are recursive?)
> So, why does this happen? cssQuery does not seem to slow by itself. It
> is the number of times is gets called that hurts my browser.
cssQuery is very slow by itself in the way we have to use it.
Unfortunately it's a known issue that cssQuery is buggy, and also we
either need to replace it with another library, and/or rewrite it so that
we can use it properly.
One issue is that when binding the inserted nodes, we would need to
search selected nodes only in the subtree we insert into the dom. This is
however not supported properly. So even if we just insert a single node,
we are forced to do a query in the entire document. This is repeated for
every kss rule that is defined.
So yes, cssQuery is the major reason for slowness of binding. There may
be others.
However this yet does not explain the number of calls for me.
> My current workaround is to update larger parts of the page than needed,
> thereby reducing the number of getHtmlIdSelector's at the expense of
> sending more data back to the client.
The thing that I don't understand is, that getHtmlIdSelector has nothing
to do with cssQuery, and I don't see how they relate.
--
Balazs Ree
More information about the Kss-devel
mailing list