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
