- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 25 Sep 2009 11:11:34 -0400
- 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.
-Boris
Received on Friday, 25 September 2009 15:12:20 UTC