Autoboxing

124 views
Skip to first unread message

gutto

unread,
Sep 11, 2011, 10:25:33 PM9/11/11
to Google Web Toolkit
Doe the fact that my client side Java code gets compiled into
JavaScript mean that it's a waste of time to worry about possible
performance problems caused by autoboxing?

Alexander Orlov

unread,
Sep 12, 2011, 5:21:10 AM9/12/11
to google-we...@googlegroups.com
I suppose: In JS there is no distinction between Integer and int. In JS there's only a single var type.

Thomas Broyer

unread,
Sep 12, 2011, 6:39:24 AM9/12/11
to google-we...@googlegroups.com
That's actually wrong.

typeof 1
"number"
typeof new Number(1)
"object"
1 instanceof Number
false
new Number(1) instanceof Number
true

But it's true however that GWT does not make any distinction between a "Number value" and a "Number object", because in practice it doesn't matter much (it only matters if you use the typeof or instanceof operators, or when some browsers are buggy –such as Firefox throwing for foo[new String("bar")] whereas foo["bar"] is OK–)

Thomas Broyer

unread,
Sep 12, 2011, 6:56:13 AM9/12/11
to google-we...@googlegroups.com
Generally speaking, it's a waste of time to worry about performance implications of such small things until you've proven that it's a performance issue for your app. Choose the right type for the job, and forget about autoboxing implications until it comes knocking at the door.
“premature optimization is the root of all evil” — Donald Knuth
See http://en.wikipedia.org/wiki/Program_optimization#When_to_optimize

FYI, Integer.valueOf is not "trivial", but I believe there are many other places in your app (and unfortunately within GWT itself) that needs to be optimized before thinking about autoboxing; starting with DOM manipulation, which is awfully slow in many browsers (much slower than creating a new JS object that wraps a number).

Y2i

unread,
Sep 12, 2011, 9:01:15 AM9/12/11
to google-we...@googlegroups.com
It's actually not buggy.  JavaScript distinguishes between objects and values, and objects are containers for values.  So when JSON { a = "b", c = 2 } is evaluated, it actually assigns values to the properties (at least in Mozilla), not objects. Values are more efficient that objects.

"bar".length is automatically converted to new String("bar").length, and the String object is discarded after the length property is used.

Y2i

unread,
Sep 12, 2011, 9:12:09 AM9/12/11
to google-we...@googlegroups.com
The most cited phrase is attributed to the man who invented his own assembly language to optimize every algorithm in his books and who spent 30 years on optimizing the the first 3 volumes :-)  He has so much yet to say to this world but because of the time he spends on optimization, I doubt we'll be able to see everything of what is planned :-(

Thomas Broyer

unread,
Sep 12, 2011, 10:13:56 AM9/12/11
to google-we...@googlegroups.com
Yes it is: https://bugzilla.mozilla.org/show_bug.cgi?id=514309

(yes, the bug actually was with hasOwnProperty rather than getting/setting properties of objects, and has been fixed back in Firefox 3.6, but still, it led to workarounds in GWT: http://code.google.com/p/google-web-toolkit/source/detail?r=7060 & http://code.google.com/p/google-web-toolkit/source/detail?r=7063 )

Please note that I was explicitly pointing out that JS distinguishes between values and objects, so the difference in typeof and instanceof is indeed not a bug (but oh so many JS libs are buggy –or should explicitly document their behavior– because their developers don't account for both String values and String objects; including GWT in a few edge cases: http://code.google.com/p/google-web-toolkit/issues/detail?id=4301 )

gutto

unread,
Sep 12, 2011, 10:49:29 PM9/12/11
to Google Web Toolkit
Please excuse my ignorance, I'm surprised to see the emulator code is
Java. I'd have thought it would be in JavaScript. Is the point that
the emulator is Java that the translator can handle?

I wonder what Integer.valueOf looks like in JavaScript?

Perhaps by explicitly writing Integer.valueOf I am forcing the
creation of additional JavaScript that would otherwise be omitted as
unnecessary?!

(I'm well aware of the "premature optimisation" adage. If by arming
yourself with a little knowledge you can avoid writing code that you
know might harm performance without sacrificing readability or
implementation time, that has to be a good thing.)

On Sep 12, 10:56 pm, Thomas Broyer <t.bro...@gmail.com> wrote:
> Generally speaking, it's a waste of time to worry about performance
> implications of such small things until you've proven that it's a
> performance issue for your app. Choose the right type for the job, and
> forget about autoboxing implications until it comes knocking at the door.
> “premature optimization is the root of all evil” — Donald Knuth
> Seehttp://en.wikipedia.org/wiki/Program_optimization#When_to_optimize
>
> FYI, Integer.valueOf<http://code.google.com/p/google-web-toolkit/source/browse/trunk/user/...>is not "trivial", but I believe there are many other places in your app (and

Y2i

unread,
Sep 12, 2011, 11:07:30 PM9/12/11
to google-we...@googlegroups.com
-style PRETTY GWT compiler option is a good tool to understand what kind of output is generated.

Reply all
Reply to author
Forward
0 new messages