I wrote two versions, one as Amit suggested with getWordPositions, and one with nextSetWord. The test unit (not counting hash and constructor tests) for the getWordPosition version was about 45% slower, while the nextSetWord version was only 37% slower. Both of these are a rather heavy penalty, but nextSetWord was the better of the two.
For the nextSetWord version, the following one line JSNI methods are used: clone slice deleteWord getWord setLengthWords These are multiple lines: trimToSize nextSetWord This is there for speed: cardinality trimToSize shortens the array by removing undefined elements at the end of the array. This prevents the length from ballooning and shortens any iteration over the array. nextSetWord iterates through the list in a way that uses properties to help iterate over sparse arrays. My previous JSNI cardinality takes 41.8% the time of the new cardinality. testCardinality runs in 2.9 seconds opposed to 1.2. When I convert it to pure java this time goes up from 1.2 to over 12 seconds. I'm not sure why this is so expensive. It must be a perfect storm for the JavaScript compiler. I can convert it to pure Java if it's prefered but the performance cost is ridiculous. These numbers come from a benchmark I did between the JSNI light version and the JSNI heavy version of the code. You can see the benchmark here: http://spreadsheets.google.com/ccc?key=rCHz6S9VRSxiPDYxbGeVyuA It currently has XP + IE7 times, but I'll probably add in results from Vista and IE8 if I get some time. I took the average of 4 runs and also the minimum of each of the 4. I think the minimum is a better benchmark, but I colored the test results based on the better of the two in favor of the new JSNI light version. Green colored functions are roughly the same speed. Yellow are up to 10% slower. Dark orange are up to 20% slower. Red is up to 30% slower. And purple are anything slower than that. The biggest problems are cardinality, equals, and intersects. "testClear" came up purple but I looked at the test and it calls set() a couple thousands times and then calls clear once, so it's not indicative of a problem with clear(). It's my guess that the compiler is not inlining the new version of set(). --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
