[gwt-contrib] Re: HashMap Optimization: return null for put and remove
I don't expect this to necessarily be done any time soon, but is there anything I need to do to make sure that it doesn't get lost? Should I file a feature request? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
Yes, please do create an issue for it, and reply to this thread with the issue id. On Tue, Jun 9, 2009 at 11:21 AM, Damon Lundin damon.lun...@gmail.comwrote: I don't expect this to necessarily be done any time soon, but is there anything I need to do to make sure that it doesn't get lost? Should I file a feature request? --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
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 damon.lun...@gmail.comwrote: 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 -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum sco...@google.com wrote: 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. Since the JRE requires returning the values (a very bad idea IMHO) then I don't see how we can short circuit it in the library. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
Sorry, lemme clarify. I mean that maybe, just maybe, there's a correct formulation of the library code such that some work can be optimized out when the return value is not used. On Fri, Jun 5, 2009 at 1:50 PM, John Tamplin j...@google.com wrote: On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum sco...@google.com wrote: 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. Since the JRE requires returning the values (a very bad idea IMHO) then I don't see how we can short circuit it in the library. -- John A. Tamplin Software Engineer (GWT), Google --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
Andres, this group is for discussing how to improve GWT. For questions about using GWT, please use google-web-tool...@googlegroups.com instead. Also it would probably be good to search that group for an appropriate, on topic thread related to JSON. On Fri, Jun 5, 2009 at 2:20 PM, ANDRES BRUN andres.b...@gmail.com wrote: Hello Everybody I'm trying to implement a code that permit me integrate PHP, GWT, MYSQL, I was testing and implementing different examples but I don't understand really good, which is the correct way to send data with JSON and principally. How I can receive that data in GWT? Please, I'm not newbie in Programation but I'm really newbie in GWT, and this version 1.6 is really difficult to learn. Somebody can help me with a good example for dummies... jajaja. Thank you -- Andrés Brun --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
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 Lundindamon.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
-~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
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 Lundindamon.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
-~--~~~~--~~--~--~---
