W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: [selectors-api] Summary of Feature Requests for v2

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 25 Sep 2009 11:11:34 -0400
Message-ID: <4ABCDDA6.6030208@mit.edu>
To: Garrett Smith <dhtmlkitchen@gmail.com>
CC: public-webapps <public-webapps@w3.org>
On 9/25/09 1:35 AM, Garrett Smith wrote:
> No, you did not say it is slow. I'm saying that your laptop is
> probably a lot more powerful than a mobile device with a browser, such
> as Blackberry9000. Do you agree with that?

Sure.  It's a pretty self-evidently true claim.

>> that said, note that on a mobile device with 128 MB of RAM the RAM is a lot
>> more likely to be a problem than the CPU in some ways.  Running out of
>> memory is strictly worse than being a little bit slower.  So a lookup table
>> may be more of a loss than a win, depending.
> An internal cache for matchesSelector (a lookup table) would be an
> implementation detail, wouldn't it?

Sure.  Sean was just saying there probably is one already; I was saying 
there isn't, along with a brief explanation of why.  You apparently 
objected to part of this explanation, but at this point I'm not quite 
sure what your objection was, exactly.  I made two statements:

1)  There seem to be no current parsed-selector caches in Webkit and
     Gecko's querySelector implementation.
2)  On my particular hardware, parsing a particular selector in Gecko
     takes approximately 5.5us.

Any conclusions to be drawn for other rendering engines, other 
selectors, or other hardware setups should be qualified appropriately 
(for example, Gecko on an N810 would probably end up closer to 500us for 
that same operation, if I recall the typical performance ratios correctly).

> The idea for QuerySelector.create is the result would be an object
> that the program could hang on to. It would not be recreated and
> garbage collected each time.

Yes, I understand the proposal.

Received on Friday, 25 September 2009 15:12:20 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:18 UTC