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

On Fri, Sep 25, 2009 at 8:11 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.
>

It seemed like a pretty safe assumption.

>>> 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.

Thanks, I got that.

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.
>

No objection. I'm not sure what you thought I was objecting to.

I wanted to point out that your year old laptop is a lot more powerful
than the Blackberry browser, which has limited memory, CPU and battery
resource.

[...]


>> 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.
>

I never doubted that, but did want to consider garbage collection,
which can also affect performance.

Garrett

Received on Wednesday, 30 September 2009 17:53:45 UTC