Re: How much slower is PRETTY mode?
Hey Rob, Whatever it was that I said that upset you so much, I apologize. I think you really need to move on. Best regards, -- Arthur Kalmenson On Mon, Apr 20, 2009 at 12:42 PM, Rob Smith wrote: > > Why is it that most of Arthurs posts either have incorrect information > or one of : > > "I haven't tried it but I think.." > "I don't know the exact numbers but.." > "I heard that xxx is good / bad but I haven't tried it.." > "I think.." > > Just search the forums. Half-knowledge more dangerous than ignorance. > Just a word of caution to new users on this forum. > > On Apr 19, 10:53 pm, Arthur Kalmenson wrote: >> > I just listened to the talk - didn't hear him say anything regarding >> > performance of long name vs short names. >> >> Oops, guess it wasn't that one, although that presentation did rock >> :P. I watched it a year ago, so my memory is rather vague there. >> >> > Even with older browsers, I don't see it being super significant - >> > 1-2% at most if it's even measurable. The execution of the javascript >> > code by the interpreter should far outweigh the cost of tokenizing the >> > input even if you have a 100 character name. The cost of doing a 100 >> > byte memcpy should be insignificant compared to all the other stuff >> > the interpreter must do. However, I could be wrong - I haven't tested >> > this in any way, so hard numbers from real-world examples would >> > probably be best. >> >> That's true, but any performance gain is good. Anyway, the main >> disadvantage of going with PRETTY is that your application ends up >> being larger so the initial start up is slower. >> >> -- >> Arthur Kalmenson >> >> On Sun, Apr 19, 2009 at 4:46 AM, Vitali Lovich wrote: >> >> > I just listened to the talk - didn't hear him say anything regarding >> > performance of long name vs short names. >> >> > The execution difference for smaller names shouldn't exist for the new >> > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, >> > Chrome). >> >> > Even with older browsers, I don't see it being super significant - >> > 1-2% at most if it's even measurable. The execution of the javascript >> > code by the interpreter should far outweigh the cost of tokenizing the >> > input even if you have a 100 character name. The cost of doing a 100 >> > byte memcpy should be insignificant compared to all the other stuff >> > the interpreter must do. However, I could be wrong - I haven't tested >> > this in any way, so hard numbers from real-world examples would >> > probably be best. >> >> > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson >> > wrote: >> >> >> I don't know the exact numbers. But if I remember correctly, during >> >> Bruce's presentation, "Faster-than-Possible Code: Deferred Binding >> >> with GWT" >> >> (http://sites.google.com/site/io/faster-than-possible-code-deferred-bi...) >> >> at Google I/O 2008, he mentioned something about smaller function and >> >> variable names executing faster then longer names. >> >> >> Also, as Vitali said, you're code is going to be rather bloated. We >> >> were accidentally running one of our apps in PRETTY and found the >> >> before compression size was 3 MB and after compression was 400kb. When >> >> we changed to OBF, the before compression size was 500kb and >> >> compressed was somewhere around 120kb. >> >> >> What's the reason that you want to run it as PRETTY? If you want to >> >> make the functions callable from regular JS, you should take a look at >> >> Ray Cromwell's excellent GWT Exporter project: >> >>http://code.google.com/p/gwt-exporter/ >> >> >> -- >> >> Arthur Kalmenson >> >> >> On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: >> >> >>> I believe that it should be the same performance in terms of >> >>> execution. You're download times will probably suffer - I wouldn't be >> >>> surprised if the code bloats by 2-3x if not more. >> >> >>> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: >> >> I'm considering deploying a version in PRETTY mode since it may solve >> a Safari 4 issue I'm having and it would also allow me to interpret >> the stack traces produced by Firefox a lot better. >> >> However, I'm wondering what experiences people have had with the >> performance of PRETTY more - how is it? >> >> Thanks in advance, >> Dobes > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
> I just listened to the talk - didn't hear him say anything regarding > performance of long name vs short names. Perhaps the faster execution happens from faster parsing since the names are shorter and faster to read in: http://code.google.com/support/bin/answer.py?answer=55203&topic=10212 -- Arthur Kalmenson On Sun, Apr 19, 2009 at 4:46 AM, Vitali Lovich wrote: > > I just listened to the talk - didn't hear him say anything regarding > performance of long name vs short names. > > The execution difference for smaller names shouldn't exist for the new > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > Chrome). > > Even with older browsers, I don't see it being super significant - > 1-2% at most if it's even measurable. The execution of the javascript > code by the interpreter should far outweigh the cost of tokenizing the > input even if you have a 100 character name. The cost of doing a 100 > byte memcpy should be insignificant compared to all the other stuff > the interpreter must do. However, I could be wrong - I haven't tested > this in any way, so hard numbers from real-world examples would > probably be best. > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > wrote: >> >> I don't know the exact numbers. But if I remember correctly, during >> Bruce's presentation, "Faster-than-Possible Code: Deferred Binding >> with GWT" >> (http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt) >> at Google I/O 2008, he mentioned something about smaller function and >> variable names executing faster then longer names. >> >> Also, as Vitali said, you're code is going to be rather bloated. We >> were accidentally running one of our apps in PRETTY and found the >> before compression size was 3 MB and after compression was 400kb. When >> we changed to OBF, the before compression size was 500kb and >> compressed was somewhere around 120kb. >> >> What's the reason that you want to run it as PRETTY? If you want to >> make the functions callable from regular JS, you should take a look at >> Ray Cromwell's excellent GWT Exporter project: >> http://code.google.com/p/gwt-exporter/ >> >> -- >> Arthur Kalmenson >> >> >> >> On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: >>> >>> I believe that it should be the same performance in terms of >>> execution. You're download times will probably suffer - I wouldn't be >>> surprised if the code bloats by 2-3x if not more. >>> >>> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: I'm considering deploying a version in PRETTY mode since it may solve a Safari 4 issue I'm having and it would also allow me to interpret the stack traces produced by Firefox a lot better. However, I'm wondering what experiences people have had with the performance of PRETTY more - how is it? Thanks in advance, Dobes > >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
I'm guilty of that too :D. Much easier to do pie in the sky calculations than to build the actual code. On Mon, Apr 20, 2009 at 12:42 PM, Rob Smith wrote: > > Why is it that most of Arthurs posts either have incorrect information > or one of : > > "I haven't tried it but I think.." > "I don't know the exact numbers but.." > "I heard that xxx is good / bad but I haven't tried it.." > "I think.." > > Just search the forums. Half-knowledge more dangerous than ignorance. > Just a word of caution to new users on this forum. > > On Apr 19, 10:53 pm, Arthur Kalmenson wrote: > > > I just listened to the talk - didn't hear him say anything regarding > > > performance of long name vs short names. > > > > Oops, guess it wasn't that one, although that presentation did rock > > :P. I watched it a year ago, so my memory is rather vague there. > > > > > Even with older browsers, I don't see it being super significant - > > > 1-2% at most if it's even measurable. The execution of the javascript > > > code by the interpreter should far outweigh the cost of tokenizing the > > > input even if you have a 100 character name. The cost of doing a 100 > > > byte memcpy should be insignificant compared to all the other stuff > > > the interpreter must do. However, I could be wrong - I haven't tested > > > this in any way, so hard numbers from real-world examples would > > > probably be best. > > > > That's true, but any performance gain is good. Anyway, the main > > disadvantage of going with PRETTY is that your application ends up > > being larger so the initial start up is slower. > > > > -- > > Arthur Kalmenson > > > > On Sun, Apr 19, 2009 at 4:46 AM, Vitali Lovich > wrote: > > > > > I just listened to the talk - didn't hear him say anything regarding > > > performance of long name vs short names. > > > > > The execution difference for smaller names shouldn't exist for the new > > > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > > > Chrome). > > > > > Even with older browsers, I don't see it being super significant - > > > 1-2% at most if it's even measurable. The execution of the javascript > > > code by the interpreter should far outweigh the cost of tokenizing the > > > input even if you have a 100 character name. The cost of doing a 100 > > > byte memcpy should be insignificant compared to all the other stuff > > > the interpreter must do. However, I could be wrong - I haven't tested > > > this in any way, so hard numbers from real-world examples would > > > probably be best. > > > > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > > > wrote: > > > > >> I don't know the exact numbers. But if I remember correctly, during > > >> Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > > >> with GWT" ( > http://sites.google.com/site/io/faster-than-possible-code-deferred-bi...) > > >> at Google I/O 2008, he mentioned something about smaller function and > > >> variable names executing faster then longer names. > > > > >> Also, as Vitali said, you're code is going to be rather bloated. We > > >> were accidentally running one of our apps in PRETTY and found the > > >> before compression size was 3 MB and after compression was 400kb. When > > >> we changed to OBF, the before compression size was 500kb and > > >> compressed was somewhere around 120kb. > > > > >> What's the reason that you want to run it as PRETTY? If you want to > > >> make the functions callable from regular JS, you should take a look at > > >> Ray Cromwell's excellent GWT Exporter project: > > >>http://code.google.com/p/gwt-exporter/ > > > > >> -- > > >> Arthur Kalmenson > > > > >> On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich > wrote: > > > > >>> I believe that it should be the same performance in terms of > > >>> execution. You're download times will probably suffer - I wouldn't > be > > >>> surprised if the code bloats by 2-3x if not more. > > > > >>> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > > > > I'm considering deploying a version in PRETTY mode since it may > solve > > a Safari 4 issue I'm having and it would also allow me to interpret > > the stack traces produced by Firefox a lot better. > > > > However, I'm wondering what experiences people have had with the > > performance of PRETTY more - how is it? > > > > Thanks in advance, > > Dobes > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
Why is it that most of Arthurs posts either have incorrect information or one of : "I haven't tried it but I think.." "I don't know the exact numbers but.." "I heard that xxx is good / bad but I haven't tried it.." "I think.." Just search the forums. Half-knowledge more dangerous than ignorance. Just a word of caution to new users on this forum. On Apr 19, 10:53 pm, Arthur Kalmenson wrote: > > I just listened to the talk - didn't hear him say anything regarding > > performance of long name vs short names. > > Oops, guess it wasn't that one, although that presentation did rock > :P. I watched it a year ago, so my memory is rather vague there. > > > Even with older browsers, I don't see it being super significant - > > 1-2% at most if it's even measurable. The execution of the javascript > > code by the interpreter should far outweigh the cost of tokenizing the > > input even if you have a 100 character name. The cost of doing a 100 > > byte memcpy should be insignificant compared to all the other stuff > > the interpreter must do. However, I could be wrong - I haven't tested > > this in any way, so hard numbers from real-world examples would > > probably be best. > > That's true, but any performance gain is good. Anyway, the main > disadvantage of going with PRETTY is that your application ends up > being larger so the initial start up is slower. > > -- > Arthur Kalmenson > > On Sun, Apr 19, 2009 at 4:46 AM, Vitali Lovich wrote: > > > I just listened to the talk - didn't hear him say anything regarding > > performance of long name vs short names. > > > The execution difference for smaller names shouldn't exist for the new > > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > > Chrome). > > > Even with older browsers, I don't see it being super significant - > > 1-2% at most if it's even measurable. The execution of the javascript > > code by the interpreter should far outweigh the cost of tokenizing the > > input even if you have a 100 character name. The cost of doing a 100 > > byte memcpy should be insignificant compared to all the other stuff > > the interpreter must do. However, I could be wrong - I haven't tested > > this in any way, so hard numbers from real-world examples would > > probably be best. > > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > > wrote: > > >> I don't know the exact numbers. But if I remember correctly, during > >> Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > >> with GWT" > >> (http://sites.google.com/site/io/faster-than-possible-code-deferred-bi...) > >> at Google I/O 2008, he mentioned something about smaller function and > >> variable names executing faster then longer names. > > >> Also, as Vitali said, you're code is going to be rather bloated. We > >> were accidentally running one of our apps in PRETTY and found the > >> before compression size was 3 MB and after compression was 400kb. When > >> we changed to OBF, the before compression size was 500kb and > >> compressed was somewhere around 120kb. > > >> What's the reason that you want to run it as PRETTY? If you want to > >> make the functions callable from regular JS, you should take a look at > >> Ray Cromwell's excellent GWT Exporter project: > >>http://code.google.com/p/gwt-exporter/ > > >> -- > >> Arthur Kalmenson > > >> On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: > > >>> I believe that it should be the same performance in terms of > >>> execution. You're download times will probably suffer - I wouldn't be > >>> surprised if the code bloats by 2-3x if not more. > > >>> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > > I'm considering deploying a version in PRETTY mode since it may solve > a Safari 4 issue I'm having and it would also allow me to interpret > the stack traces produced by Firefox a lot better. > > However, I'm wondering what experiences people have had with the > performance of PRETTY more - how is it? > > Thanks in advance, > Dobes --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
> I just listened to the talk - didn't hear him say anything regarding > performance of long name vs short names. Oops, guess it wasn't that one, although that presentation did rock :P. I watched it a year ago, so my memory is rather vague there. > Even with older browsers, I don't see it being super significant - > 1-2% at most if it's even measurable. The execution of the javascript > code by the interpreter should far outweigh the cost of tokenizing the > input even if you have a 100 character name. The cost of doing a 100 > byte memcpy should be insignificant compared to all the other stuff > the interpreter must do. However, I could be wrong - I haven't tested > this in any way, so hard numbers from real-world examples would > probably be best. That's true, but any performance gain is good. Anyway, the main disadvantage of going with PRETTY is that your application ends up being larger so the initial start up is slower. -- Arthur Kalmenson On Sun, Apr 19, 2009 at 4:46 AM, Vitali Lovich wrote: > > I just listened to the talk - didn't hear him say anything regarding > performance of long name vs short names. > > The execution difference for smaller names shouldn't exist for the new > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > Chrome). > > Even with older browsers, I don't see it being super significant - > 1-2% at most if it's even measurable. The execution of the javascript > code by the interpreter should far outweigh the cost of tokenizing the > input even if you have a 100 character name. The cost of doing a 100 > byte memcpy should be insignificant compared to all the other stuff > the interpreter must do. However, I could be wrong - I haven't tested > this in any way, so hard numbers from real-world examples would > probably be best. > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > wrote: >> >> I don't know the exact numbers. But if I remember correctly, during >> Bruce's presentation, "Faster-than-Possible Code: Deferred Binding >> with GWT" >> (http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt) >> at Google I/O 2008, he mentioned something about smaller function and >> variable names executing faster then longer names. >> >> Also, as Vitali said, you're code is going to be rather bloated. We >> were accidentally running one of our apps in PRETTY and found the >> before compression size was 3 MB and after compression was 400kb. When >> we changed to OBF, the before compression size was 500kb and >> compressed was somewhere around 120kb. >> >> What's the reason that you want to run it as PRETTY? If you want to >> make the functions callable from regular JS, you should take a look at >> Ray Cromwell's excellent GWT Exporter project: >> http://code.google.com/p/gwt-exporter/ >> >> -- >> Arthur Kalmenson >> >> >> >> On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: >>> >>> I believe that it should be the same performance in terms of >>> execution. You're download times will probably suffer - I wouldn't be >>> surprised if the code bloats by 2-3x if not more. >>> >>> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: I'm considering deploying a version in PRETTY mode since it may solve a Safari 4 issue I'm having and it would also allow me to interpret the stack traces produced by Firefox a lot better. However, I'm wondering what experiences people have had with the performance of PRETTY more - how is it? Thanks in advance, Dobes > >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
I've turned PRETTY on and one thing I have noticed is that it increases my compile times by about 20%-25% - from 430 seconds to ~ 570, which sucks. But I guess 7 minutes to 9 isn't that bad - once I passed the 5 minute mark I leaned to go surf the web while I wait .. :-/ On Sun, Apr 19, 2009 at 4:54 PM, Vitali Lovich wrote: > So wait, even with Firebug disabled in FF2 you saw a 10% hit? > > > On Sun, Apr 19, 2009 at 7:44 PM, John Gunther > wrote: > >> >> A while back I was doing some performance tests and my recollection >> was, for that application, in FF2, it was something like 10% slower in >> PRETTY. This was with GWT 1.4. Not a lot, but just enough that I >> decided not to performance test in PRETTY. >> >> (The big performance impact in FF2 is if Firebug is completely >> disabled or not. Firebug must be completely disabled (via Tools/ >> Addons) with a FF restart to get the real numbers (plus just about >> everything looks like it has a memory leak with Firebug on)) >> >> John >> >> On Apr 19, 10:20 am, Dobes Vandermeer wrote: >> > Okay, that's helpful. >> > Maybe it's worth slowing down the downloads for a while to get some >> better >> > insight into some of the errors customers are getting, since it'll allow >> me >> > to read the stack traces Firefox includes in the exceptions. >> > >> > >> > >> > On Sun, Apr 19, 2009 at 1:46 AM, Vitali Lovich >> wrote: >> > >> > > I just listened to the talk - didn't hear him say anything regarding >> > > performance of long name vs short names. >> > >> > > The execution difference for smaller names shouldn't exist for the new >> > > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, >> > > Chrome). >> > >> > > Even with older browsers, I don't see it being super significant - >> > > 1-2% at most if it's even measurable. The execution of the javascript >> > > code by the interpreter should far outweigh the cost of tokenizing the >> > > input even if you have a 100 character name. The cost of doing a 100 >> > > byte memcpy should be insignificant compared to all the other stuff >> > > the interpreter must do. However, I could be wrong - I haven't tested >> > > this in any way, so hard numbers from real-world examples would >> > > probably be best. >> > >> > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson >> > > wrote: >> > >> > > > I don't know the exact numbers. But if I remember correctly, during >> > > > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding >> > > > with GWT" ( >> > >http://sites.google.com/site/io/faster-than-possible-code-deferred-bi. >> .. >> > > ) >> > > > at Google I/O 2008, he mentioned something about smaller function >> and >> > > > variable names executing faster then longer names. >> > >> > > > Also, as Vitali said, you're code is going to be rather bloated. We >> > > > were accidentally running one of our apps in PRETTY and found the >> > > > before compression size was 3 MB and after compression was 400kb. >> When >> > > > we changed to OBF, the before compression size was 500kb and >> > > > compressed was somewhere around 120kb. >> > >> > > > What's the reason that you want to run it as PRETTY? If you want to >> > > > make the functions callable from regular JS, you should take a look >> at >> > > > Ray Cromwell's excellent GWT Exporter project: >> > > >http://code.google.com/p/gwt-exporter/ >> > >> > > > -- >> > > > Arthur Kalmenson >> > >> > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich >> > > wrote: >> > >> > > >> I believe that it should be the same performance in terms of >> > > >> execution. You're download times will probably suffer - I wouldn't >> be >> > > >> surprised if the code bloats by 2-3x if not more. >> > >> > > >> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: >> > >> > > >>> I'm considering deploying a version in PRETTY mode since it may >> solve >> > > >>> a Safari 4 issue I'm having and it would also allow me to >> interpret >> > > >>> the stack traces produced by Firefox a lot better. >> > >> > > >>> However, I'm wondering what experiences people have had with the >> > > >>> performance of PRETTY more - how is it? >> > >> > > >>> Thanks in advance, >> > > >>> Dobes >> > >> > -- >> > >> > Dobes Vandermeer >> > Director, Habitsoft Inc. >> > dob...@habitsoft.com >> > 778-891-2922 >> >> > > > > -- Dobes Vandermeer Director, Habitsoft Inc. dob...@habitsoft.com 778-891-2922 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
So wait, even with Firebug disabled in FF2 you saw a 10% hit? On Sun, Apr 19, 2009 at 7:44 PM, John Gunther wrote: > > A while back I was doing some performance tests and my recollection > was, for that application, in FF2, it was something like 10% slower in > PRETTY. This was with GWT 1.4. Not a lot, but just enough that I > decided not to performance test in PRETTY. > > (The big performance impact in FF2 is if Firebug is completely > disabled or not. Firebug must be completely disabled (via Tools/ > Addons) with a FF restart to get the real numbers (plus just about > everything looks like it has a memory leak with Firebug on)) > > John > > On Apr 19, 10:20 am, Dobes Vandermeer wrote: > > Okay, that's helpful. > > Maybe it's worth slowing down the downloads for a while to get some > better > > insight into some of the errors customers are getting, since it'll allow > me > > to read the stack traces Firefox includes in the exceptions. > > > > > > > > On Sun, Apr 19, 2009 at 1:46 AM, Vitali Lovich > wrote: > > > > > I just listened to the talk - didn't hear him say anything regarding > > > performance of long name vs short names. > > > > > The execution difference for smaller names shouldn't exist for the new > > > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > > > Chrome). > > > > > Even with older browsers, I don't see it being super significant - > > > 1-2% at most if it's even measurable. The execution of the javascript > > > code by the interpreter should far outweigh the cost of tokenizing the > > > input even if you have a 100 character name. The cost of doing a 100 > > > byte memcpy should be insignificant compared to all the other stuff > > > the interpreter must do. However, I could be wrong - I haven't tested > > > this in any way, so hard numbers from real-world examples would > > > probably be best. > > > > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > > > wrote: > > > > > > I don't know the exact numbers. But if I remember correctly, during > > > > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > > > > with GWT" ( > > >http://sites.google.com/site/io/faster-than-possible-code-deferred-bi. > .. > > > ) > > > > at Google I/O 2008, he mentioned something about smaller function and > > > > variable names executing faster then longer names. > > > > > > Also, as Vitali said, you're code is going to be rather bloated. We > > > > were accidentally running one of our apps in PRETTY and found the > > > > before compression size was 3 MB and after compression was 400kb. > When > > > > we changed to OBF, the before compression size was 500kb and > > > > compressed was somewhere around 120kb. > > > > > > What's the reason that you want to run it as PRETTY? If you want to > > > > make the functions callable from regular JS, you should take a look > at > > > > Ray Cromwell's excellent GWT Exporter project: > > > >http://code.google.com/p/gwt-exporter/ > > > > > > -- > > > > Arthur Kalmenson > > > > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich > > > wrote: > > > > > >> I believe that it should be the same performance in terms of > > > >> execution. You're download times will probably suffer - I wouldn't > be > > > >> surprised if the code bloats by 2-3x if not more. > > > > > >> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > > > > > >>> I'm considering deploying a version in PRETTY mode since it may > solve > > > >>> a Safari 4 issue I'm having and it would also allow me to interpret > > > >>> the stack traces produced by Firefox a lot better. > > > > > >>> However, I'm wondering what experiences people have had with the > > > >>> performance of PRETTY more - how is it? > > > > > >>> Thanks in advance, > > > >>> Dobes > > > > -- > > > > Dobes Vandermeer > > Director, Habitsoft Inc. > > dob...@habitsoft.com > > 778-891-2922 > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
A while back I was doing some performance tests and my recollection was, for that application, in FF2, it was something like 10% slower in PRETTY. This was with GWT 1.4. Not a lot, but just enough that I decided not to performance test in PRETTY. (The big performance impact in FF2 is if Firebug is completely disabled or not. Firebug must be completely disabled (via Tools/ Addons) with a FF restart to get the real numbers (plus just about everything looks like it has a memory leak with Firebug on)) John On Apr 19, 10:20 am, Dobes Vandermeer wrote: > Okay, that's helpful. > Maybe it's worth slowing down the downloads for a while to get some better > insight into some of the errors customers are getting, since it'll allow me > to read the stack traces Firefox includes in the exceptions. > > > > On Sun, Apr 19, 2009 at 1:46 AM, Vitali Lovich wrote: > > > I just listened to the talk - didn't hear him say anything regarding > > performance of long name vs short names. > > > The execution difference for smaller names shouldn't exist for the new > > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > > Chrome). > > > Even with older browsers, I don't see it being super significant - > > 1-2% at most if it's even measurable. The execution of the javascript > > code by the interpreter should far outweigh the cost of tokenizing the > > input even if you have a 100 character name. The cost of doing a 100 > > byte memcpy should be insignificant compared to all the other stuff > > the interpreter must do. However, I could be wrong - I haven't tested > > this in any way, so hard numbers from real-world examples would > > probably be best. > > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > > wrote: > > > > I don't know the exact numbers. But if I remember correctly, during > > > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > > > with GWT" ( > >http://sites.google.com/site/io/faster-than-possible-code-deferred-bi... > > ) > > > at Google I/O 2008, he mentioned something about smaller function and > > > variable names executing faster then longer names. > > > > Also, as Vitali said, you're code is going to be rather bloated. We > > > were accidentally running one of our apps in PRETTY and found the > > > before compression size was 3 MB and after compression was 400kb. When > > > we changed to OBF, the before compression size was 500kb and > > > compressed was somewhere around 120kb. > > > > What's the reason that you want to run it as PRETTY? If you want to > > > make the functions callable from regular JS, you should take a look at > > > Ray Cromwell's excellent GWT Exporter project: > > >http://code.google.com/p/gwt-exporter/ > > > > -- > > > Arthur Kalmenson > > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich > > wrote: > > > >> I believe that it should be the same performance in terms of > > >> execution. You're download times will probably suffer - I wouldn't be > > >> surprised if the code bloats by 2-3x if not more. > > > >> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > > > >>> I'm considering deploying a version in PRETTY mode since it may solve > > >>> a Safari 4 issue I'm having and it would also allow me to interpret > > >>> the stack traces produced by Firefox a lot better. > > > >>> However, I'm wondering what experiences people have had with the > > >>> performance of PRETTY more - how is it? > > > >>> Thanks in advance, > > >>> Dobes > > -- > > Dobes Vandermeer > Director, Habitsoft Inc. > dob...@habitsoft.com > 778-891-2922 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
Okay, that's helpful. Maybe it's worth slowing down the downloads for a while to get some better insight into some of the errors customers are getting, since it'll allow me to read the stack traces Firefox includes in the exceptions. On Sun, Apr 19, 2009 at 1:46 AM, Vitali Lovich wrote: > > I just listened to the talk - didn't hear him say anything regarding > performance of long name vs short names. > > The execution difference for smaller names shouldn't exist for the new > generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, > Chrome). > > Even with older browsers, I don't see it being super significant - > 1-2% at most if it's even measurable. The execution of the javascript > code by the interpreter should far outweigh the cost of tokenizing the > input even if you have a 100 character name. The cost of doing a 100 > byte memcpy should be insignificant compared to all the other stuff > the interpreter must do. However, I could be wrong - I haven't tested > this in any way, so hard numbers from real-world examples would > probably be best. > > On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson > wrote: > > > > I don't know the exact numbers. But if I remember correctly, during > > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > > with GWT" ( > http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt > ) > > at Google I/O 2008, he mentioned something about smaller function and > > variable names executing faster then longer names. > > > > Also, as Vitali said, you're code is going to be rather bloated. We > > were accidentally running one of our apps in PRETTY and found the > > before compression size was 3 MB and after compression was 400kb. When > > we changed to OBF, the before compression size was 500kb and > > compressed was somewhere around 120kb. > > > > What's the reason that you want to run it as PRETTY? If you want to > > make the functions callable from regular JS, you should take a look at > > Ray Cromwell's excellent GWT Exporter project: > > http://code.google.com/p/gwt-exporter/ > > > > -- > > Arthur Kalmenson > > > > > > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich > wrote: > >> > >> I believe that it should be the same performance in terms of > >> execution. You're download times will probably suffer - I wouldn't be > >> surprised if the code bloats by 2-3x if not more. > >> > >> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > >>> > >>> I'm considering deploying a version in PRETTY mode since it may solve > >>> a Safari 4 issue I'm having and it would also allow me to interpret > >>> the stack traces produced by Firefox a lot better. > >>> > >>> However, I'm wondering what experiences people have had with the > >>> performance of PRETTY more - how is it? > >>> > >>> Thanks in advance, > >>> Dobes > >>> > >>> > >>> > > >>> > >> > >> > > >> > > > > > > > > > > > -- Dobes Vandermeer Director, Habitsoft Inc. dob...@habitsoft.com 778-891-2922 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
Thanks ... that helps a little. I wanted PRETTY so I could interpret the stack traces that show up in Firefox - there are various stack traces showing up in customer's machines that I am now seeing on my development environment. Also, there's a bug in Safari 4 beta where it can't handle my obfuscated GWT code since a line gets too long (or something). So PRETTY would be helpful for these. On Sat, Apr 18, 2009 at 9:25 PM, Arthur Kalmenson wrote: > > I don't know the exact numbers. But if I remember correctly, during > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > with GWT" ( > http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt > ) > at Google I/O 2008, he mentioned something about smaller function and > variable names executing faster then longer names. > > Also, as Vitali said, you're code is going to be rather bloated. We > were accidentally running one of our apps in PRETTY and found the > before compression size was 3 MB and after compression was 400kb. When > we changed to OBF, the before compression size was 500kb and > compressed was somewhere around 120kb. > > What's the reason that you want to run it as PRETTY? If you want to > make the functions callable from regular JS, you should take a look at > Ray Cromwell's excellent GWT Exporter project: > http://code.google.com/p/gwt-exporter/ > > -- > Arthur Kalmenson > > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: > > > > I believe that it should be the same performance in terms of > > execution. You're download times will probably suffer - I wouldn't be > > surprised if the code bloats by 2-3x if not more. > > > > On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > >> > >> I'm considering deploying a version in PRETTY mode since it may solve > >> a Safari 4 issue I'm having and it would also allow me to interpret > >> the stack traces produced by Firefox a lot better. > >> > >> However, I'm wondering what experiences people have had with the > >> performance of PRETTY more - how is it? > >> > >> Thanks in advance, > >> Dobes > >> > >> > >> > > >> > > > > > > > > > > > -- Dobes Vandermeer Director, Habitsoft Inc. dob...@habitsoft.com 778-891-2922 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
I just listened to the talk - didn't hear him say anything regarding performance of long name vs short names. The execution difference for smaller names shouldn't exist for the new generation of browsers using JIT for javascript (i.e. FF3.5, Safair 4, Chrome). Even with older browsers, I don't see it being super significant - 1-2% at most if it's even measurable. The execution of the javascript code by the interpreter should far outweigh the cost of tokenizing the input even if you have a 100 character name. The cost of doing a 100 byte memcpy should be insignificant compared to all the other stuff the interpreter must do. However, I could be wrong - I haven't tested this in any way, so hard numbers from real-world examples would probably be best. On Sun, Apr 19, 2009 at 12:25 AM, Arthur Kalmenson wrote: > > I don't know the exact numbers. But if I remember correctly, during > Bruce's presentation, "Faster-than-Possible Code: Deferred Binding > with GWT" > (http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt) > at Google I/O 2008, he mentioned something about smaller function and > variable names executing faster then longer names. > > Also, as Vitali said, you're code is going to be rather bloated. We > were accidentally running one of our apps in PRETTY and found the > before compression size was 3 MB and after compression was 400kb. When > we changed to OBF, the before compression size was 500kb and > compressed was somewhere around 120kb. > > What's the reason that you want to run it as PRETTY? If you want to > make the functions callable from regular JS, you should take a look at > Ray Cromwell's excellent GWT Exporter project: > http://code.google.com/p/gwt-exporter/ > > -- > Arthur Kalmenson > > > > On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: >> >> I believe that it should be the same performance in terms of >> execution. You're download times will probably suffer - I wouldn't be >> surprised if the code bloats by 2-3x if not more. >> >> On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: >>> >>> I'm considering deploying a version in PRETTY mode since it may solve >>> a Safari 4 issue I'm having and it would also allow me to interpret >>> the stack traces produced by Firefox a lot better. >>> >>> However, I'm wondering what experiences people have had with the >>> performance of PRETTY more - how is it? >>> >>> Thanks in advance, >>> Dobes >>> >>> >>> > >>> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
I don't know the exact numbers. But if I remember correctly, during Bruce's presentation, "Faster-than-Possible Code: Deferred Binding with GWT" (http://sites.google.com/site/io/faster-than-possible-code-deferred-binding-with-gwt) at Google I/O 2008, he mentioned something about smaller function and variable names executing faster then longer names. Also, as Vitali said, you're code is going to be rather bloated. We were accidentally running one of our apps in PRETTY and found the before compression size was 3 MB and after compression was 400kb. When we changed to OBF, the before compression size was 500kb and compressed was somewhere around 120kb. What's the reason that you want to run it as PRETTY? If you want to make the functions callable from regular JS, you should take a look at Ray Cromwell's excellent GWT Exporter project: http://code.google.com/p/gwt-exporter/ -- Arthur Kalmenson On Sat, Apr 18, 2009 at 1:46 AM, Vitali Lovich wrote: > > I believe that it should be the same performance in terms of > execution. You're download times will probably suffer - I wouldn't be > surprised if the code bloats by 2-3x if not more. > > On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: >> >> I'm considering deploying a version in PRETTY mode since it may solve >> a Safari 4 issue I'm having and it would also allow me to interpret >> the stack traces produced by Firefox a lot better. >> >> However, I'm wondering what experiences people have had with the >> performance of PRETTY more - how is it? >> >> Thanks in advance, >> Dobes >> >> >> > >> > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
Re: How much slower is PRETTY mode?
I believe that it should be the same performance in terms of execution. You're download times will probably suffer - I wouldn't be surprised if the code bloats by 2-3x if not more. On Fri, Apr 17, 2009 at 11:40 PM, Dobes wrote: > > I'm considering deploying a version in PRETTY mode since it may solve > a Safari 4 issue I'm having and it would also allow me to interpret > the stack traces produced by Firefox a lot better. > > However, I'm wondering what experiences people have had with the > performance of PRETTY more - how is it? > > Thanks in advance, > Dobes > > > > > --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
How much slower is PRETTY mode?
I'm considering deploying a version in PRETTY mode since it may solve a Safari 4 issue I'm having and it would also allow me to interpret the stack traces produced by Firefox a lot better. However, I'm wondering what experiences people have had with the performance of PRETTY more - how is it? Thanks in advance, Dobes --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
