Add configuration to set Map implementation used in

[nmorel]

Add configuration to set Map implementation used in

[nmorel]

I don't think you gonna gain much on serializer. I already try when I optimize a bit the code. I did it for deserializer but on serializer, I almost only use the entrySet() method and compared to the gwt implementation, it's almost the same if I remember. GWT already have a special implementation when the key is a String.

But I can give an other try and see how it goes.

[reinert]

GWT already have a special implementation when the key is a String.

I really didn't know about that! I do want to see this implementation! Do you have the resource for this? Thanks for the info!!

[reinert]

I found this resource, but it is a proposal..
http://code.google.com/p/google-web-toolkit/wiki/HashMapOptimization

[reinert]

But I can give an other try and see how it goes.

It's on my roadmap create a benchmark comparing my JsCollections API with default GWT JRE implementations. I would be glad if you could try this simple switch and give me some feedback.

In JsMap implementation, I cache the keys in order to avoid iterating over them when calling keyset() for example. (Notice that native Object.keys() has a linear cost)

LightMap is based on JsMap, so I believe it would cause some performance gain.

[nmorel]

It's directly inside the GWT emulation :
https://gwt.googlesource.com/gwt/+/master/user/super/com/google/gwt/emul/java/util/AbstractHashMap.java

[nmorel]

I tried it but I didn't see a performance gain. I only tested on chromium though.
I tried with different data size and the average time is the same.

In my test case, I only use the put and entrySet method on map.

One side note, your collection classes use the diamond operator and are only java 7+ compatible. I had to change that to use them in my code.

[reinert]

Hum... thanks for the feedback! I would like to compare memory usage too, but this I will do later. Anyway, I guess I won't spend more energy with collections. My original intention was to provide java.util implementations supporting native arrays and this goal has been achieved.

[nmorel]

It does not mean you have to give up on them :) I only used a small subset
and in a specific use case. It needs more test if you really want to know
how it compares.

What do you mean by supporting native arrays ?
Le 4 juin 2014 23:05, "Danilo Reinert" [email protected] a écrit :

Hum... thanks for the feedback! I would like to compare memory usage too,
but this I will do later. Anyway, I guess I won't spend more energy with
collections. My original intention was to provide java.util implementations
supporting native arrays and this goal has been achieved.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[reinert]

What do you mean by supporting native arrays ?

JsArrayList accepts a JsArray in its constructor. JsArraySet too. Also I implemented an Iterator for jsArrays (JsArrayIterator).

I did not give up from my collections api :)
I have many other priorities to work on, so I'll just not improve this for now.

My next efforts are to develop a simple Promises API in -Core. Then I'll refactor the -HTTP to use it. Later I need to implement autobinding in -Databind using Generators.