That's... strange but cool! On Fri, Jun 5, 2009 at 8:43 PM, Ray Cromwell <cromwell...@gmail.com> wrote:
> > 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<damon.lun...@gmail.com> > 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 -~----------~----~----~----~------~----~------~--~---
