This would definitely be a good thing to look into, but I expect it's slightly tricky. Maybe the library code itself could be hacked on until a suitable formulation was found.
On Fri, Jun 5, 2009 at 11:52 AM, Damon Lundin <[email protected]>wrote: > > I have an idea of an optimization of usages of HashMap. I have > recently switched from using the FastStringMap to using a normal > HashMap since the performance difference isn't as significant as it > once was. However, there is one point where I was able to still make > the FastStringMap faster. I overrode the put and remove methods and > had them return null instead of performing a get to fetch the current > value for the keys. In the vast majority of cases, the client never > uses the values returned from put or remove which just wastes the gets > to look them up. I tried a test that does 100,000 puts and gets and I > have found that my version which returns null in the put is almost > twice as fast as the version which does not. > > If the compiler can devirtualize a variable to a java.util.HashMap and > it sees that the return value is not used, could the compilter > substitute a different method call to a different version of put and > remove that just return null (or perhaps nothing)? > > If you want to see the details of my tests, you can read the blog post > I recently put up regarding our usage of FastStringMap: > http://development.lombardi.com/?p=797 > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
