[gwt-contrib] Re: HashMap Optimization: return null for put and remove
By the way, in case it's not obvious, having Map.put() return the old value is usually good for performance. Without it, coders must sometimes do a query of the map followed by a put, which means that the same key is looked up twice. To contrast, returning a value that is at hand but is not actually used should normally be free. It's currently not. All this is to say, we might or might not want to update the API. It's more of a win-win if the API returns the value, but the compiler can still optimize that return to nothing in cases where the value isn't actually used. Also, I'd like to emphasize Ray's comment that it's shouldn't be out of the question for the compiler to understand the lightweight collections. If tons of GWT code uses the new hash map, then a "special purpose" optimization for that specific class could still have a lot of benefit. That said, does it matter for java.util.HashMap::put? I would think that having to implement a hash table already consumes so much code that the method isn't inlineable anyway, even without the extra returned value. In that case, having an extra "return foo" at the end of the method is cheap, just like the case on the JVM. Lex --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: HashMap Optimization: return null for put and remove
The issue is 3743 - http://code.google.com/p/google-web-toolkit/issues/detail?id=3743 --~--~-~--~~~---~--~~ 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 wrote: > > 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
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
That's... strange but cool!
On Fri, Jun 5, 2009 at 8:43 PM, Ray Cromwell 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 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
> 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
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 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 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
Thank you Scott and Excuse me. Bye On Fri, Jun 5, 2009 at 2:49 PM, Scott Blum wrote: > 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 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 >> >> -- ANDRES BRUN WebSite Andres Brun http://www.andresbrun.tk Blog - http://doyan2007.blogspot.com/ WebSite http://www.prolinetsystems.tk GWT - http://groups.google.com/group/Google-Web-Toolkit-Contributors --~--~-~--~~~---~--~~ 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 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
I think this is an important insight for any attempt to build a faster, lighter-weight collections library. The JRE collections design has been a problem for a lot of reasons, this certainly among them. It's probably unrealistic for us to simply break the behavior of any class implementing Map (for example), but we definitely *can* design a map interface that doesn't have these ugly warts in it. On Fri, Jun 5, 2009 at 1:53 PM, Scott Blum wrote: > 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 wrote: > >> On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum 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
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
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 wrote: > On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum 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
On Fri, Jun 5, 2009 at 1:21 PM, Scott Blum 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
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 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 -~--~~~~--~~--~--~---
