[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