A strong +1 (+2?) to the idea of having a super-fast JsStringMap.
Assuming that John's concern about special cases like 'watch' can be dealt
with, I think this would be a valuable addition.
There are a few things that aren't really clear to me though:1. What's the
point of having a FastMap<K,V> that selects its implementation based on
web/hosted mode? I can see how the JS implementation might be a little
slower in hosted mode, but I'm not sure that this warrants adding that much
complexity.
2. Can you actually use an arbitrary object as the key type? Based on the
native put() implementation (map[key] = value), I'd guess not. I may be
missing something, but I don't see any way to limit the key type as it's
currently specified.
3. The whole JSMapAdapter thing seems like it defeats the purpose of having
a fast map implementation. If I were ever going to use this, it seems like
it would make more sense just to use the regular HashMap, since it's going
to be sub-optimal either way.
One other question: Does the implementation of AbstractJsMap.size() really
have to be O(N)? If that's the case, we might actually want to avoid having
it (or maintain the information some other way), since the whole point is to
provide exactly the map interface that can be made fast, whatever those
restrictions may be.
On Fri, Sep 5, 2008 at 12:09 AM, Bruce Johnson <[EMAIL PROTECTED]> wrote:
> I'm in favor of something much less designed. The extra object (i.e. the
> internal JSO) seems unnecessarily costly, considering that we're not trying
> to comply with an existing API such as the JRE Map interface.
> Why not avoid an abstract base class that necessitates polymorphism,
> adapter objects, etc., and instead use a JSO directly?
>
> final class JsMapStringObject<V> extends JavaScriptObject {
> public native V get(String k) /*-{ return this[k]; }-*/;
> public native void put(String k, V v) /*-{ this[k] = v; }-*/;
> }
>
> This is admittedly less than full-featured and might need a little more (of
> course), but if the point is to do something special-purpose that's fast,
> then shouldn't we take it all the way?
>
> In the same vein, we could also create:
>
> JsMapStringInt
> JsMapIntObject
> JsMapIntInt
> ...and maybe others...
>
>
> On Thu, Sep 4, 2008 at 11:45 PM, Emily Crutcher <[EMAIL PROTECTED]> wrote:
>
>> Ah, I see what happened, when tortoise makes a branch of the working
>> directory it, logically enough, does not include files which have not been
>> officially added to trunk. The files should be there now.
>>
>>
>> On Thu, Sep 4, 2008 at 7:36 PM, Folke <[EMAIL PROTECTED]> wrote:
>>
>>>
>>> Hi Emily
>>>
>>> Did you commit the files? I'm really interested in your
>>> implementation. This directory is empty:
>>>
>>> http://code.google.com/p/google-web-toolkit-incubator/source/browse/branches/ecc/collectionsReview/src/com/google/gwt/gen2/collection
>>>
>>> Folke
>>>
>>>
>>> On Sep 5, 12:28 am, "Emily Crutcher" <[EMAIL PROTECTED]> wrote:
>>> > John, master of JRE collections, Could you review this?
>>> >
>>> > For big applications, map's performance can end up being a bottleneck.
>>> This
>>> > code review introduces the AbstractJsMap, which is a slightly modified
>>> API
>>> > so that we can create faster map implementations.
>>> >
>>> > The code contains new directories, so here is a read-only branch with
>>> the
>>> > code in it:
>>> http://code.google.com/p/google-web-toolkit-incubator/source/browse/#...
>>> >
>>> > Attached is the benchmark for putting then getting 1000 through 10,000
>>> > strings, where HashMap is compared to the new JsStringMap. For the
>>> compiled
>>> > put/get benchmark, it is between 300%-500% faster.
>>> >
>>> > Thanks,
>>> >
>>> > Emily
>>> >
>>> > --
>>> > "There are only 10 types of people in the world: Those who understand
>>> > binary, and those who don't"
>>> >
>>> > Mozilla4_003.png
>>> > 22KViewDownload
>>> >
>>> > report-JsStringMap.xml
>>> > 11KViewDownload
>>>
>>>
>>
>>
>> --
>> "There are only 10 types of people in the world: Those who understand
>> binary, and those who don't"
>>
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
