It could do it using a technique called 'semantic inlining' where the compiler has builtin knowledge of the Map interface and treats it in a magic fashion. To do it in a more general purpose fashion would be very tricky. If put() or remove() could be inlined by the compiler normally, then standard techniques like liveness analysis/dead code elimination could remove the fetch since after inlining, the compiler could see that the calling block never uses the value.
I hesitate to suggest the following, but here goes. Perl is not a context-free language, methods can be evaluated in differing contexts and functions can detect this and choose to act differently based on what they are being assigned to, see: http://docstore.mik.ua/orelly/perl/cookbook/ch10_07.htm Quote: if (wantarray()) { # list context } elsif (defined wantarray()) { # scalar context } else { # void context } Note that last one, now imagine a magic GWT function, GWT.wantsValue() that returns true if the current JMethod is being executed as part of an expression that is assigned or passed as a parameter to something, false otherwise. You could then rewrite HashMap.put() as public <T> put(S key, T val) { if(GWT.wantsValue()) { // call putSlow() which returns a value } else { // call putFast(), return null } } -Ray On Fri, Jun 5, 2009 at 11:52 PM, 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 -~----------~----~----~----~------~----~------~--~---
