2010/12/19 Garrett Smith <[email protected]>: > [...] > Typical library author FUD, and typical of Google developers. I'[ve > already gone over this with the author of GWT project. ><http://groups.google.com/group/comp.lang.javascript/browse_thread/thread/566395fc193eb4f1/1120d91202f005cd?hl=en&ie=UTF-8> > [...] > > And as evidenced by the test result, creating an object with > properties isn't any faster than modifying an object in scope. > http://dhtmlkitchen.com/jstest/variable-performance.html > > And with the fine work on V8 and Jaegermonkey, closure performance has > improved drastically. > > See also: > Blog of Mozilla Engineer Dave Mandelin: <http://blog.mozilla.com/dmandelin/> > Bugzilla Bug 517164 - (ClosurePerf) [meta] Make Closure Access Blindingly Fast > <https://bugzilla.mozilla.org/show_bug.cgi?id=517164> > > Massive improvements in Jaegermonkey on <http://arewefastyet.com/> > Brendan talks about those here: > <http://www.aminutewithbrendan.com/pages/20101213> >
I like your tests. I would love to see how new versions of browsers perform. I ran the tests on my computer out of curiosity: Windows 7 Ultimate on an AMD 64 x2 Dual Core 5200+ (2.7GHz) https://spreadsheets.google.com/pub?key=0AkXKo_3bj2oXdDRfUFlSWFJxdlJvbDJPWl85dlFqREE&hl=en&single=true&gid=0&output=html - The old results are from your table. So comparing the two is of course nonsense. - Opera 11 crashes for me after the first test. - IE 9 gives "Error: Object doesn't support this property or method" for `fdoc.clear();` so it was commented out. - Firefox 4.0b8pre is blazingly fast for everything except closures and objCreate. I mean closures are fast, but still not on pair with Chrome. - Chrome 10 (Canary build with Crankshaft): ok performance for everything, but closures are like a miracle here. - IE 9 is a bit strange. 1135ms for localRead? Something is not right here. Maybe I need to reinstall. Better yet you could test these browsers on your computer, and so the numbers become comparable with the old ones. > Matt added to that: > > | Attempting to optimize by messing with identifier resolution and > | scope chains makes assumptions about browser implementation > | that may not be true, and may in fact break optimizations that would > | have resulted in even _faster_ performance had you not tried to > | mess with it! > [...] Great point. > SUre, any outside file can get at that. Say pornwar3zads.js tries to > read goog._secret, sure, it can! If `goog` is a global identifier, > then why wouldn't it be able to? > > Now if closure compiler is needed to prevent that privacy, you're not > getting real privacy at all, just a warning and only when that tool is > used. > -- Because of the way how @private works, yes, it's not really private. It's more for those coming from Java or compiled languages who used to catch such errors at "compile time". I do think that @private in its current form is not doing much, because properties pre/postfixed with _ are already marked as private, and one has to be a bit silly if messes with such members of an object from outside. But if pornwar3zads.js is successfully injected to your site it can do harm no matter if closures are used or not. Because it can access and mess with built-in and host objects you're using throughout your application. It's much more of a concern. Finally, it may well be that the OOP system only kicks in if ADVANCED more is turned on, and it's by definition meant to be processing you're whole application. Still no excuse if you want real privacy of course. - Balázs > Garrett > > -- > To view archived discussions from the original JSMentors Mailman list: > http://www.mail-archive.com/[email protected]/ > > To search via a non-Google archive, visit here: > http://www.mail-archive.com/[email protected]/ > > To unsubscribe from this group, send email to > [email protected] > -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
