On 12/18/10, Balázs Galambosi <[email protected]> wrote: >> Learn interleaved reply; do not top post. > > Ok, my friend :)
Thanks. > > >> <touchy> >> A more likely explanation is that the authors of Closure COmpiler do >> not understand [[Scope]]. >> </touchy> > In discussions with the CC team, I presented the idea of building a tree of scope to allow inlining. They did discuss any of these ideas with me, pointed me to a Java file that shows how CC optimized [[Scope]] for invalid ES syntax (nonstandard "function statement" ES extensions, as seen in source code of GMail), and then linked to a then (and still) outdated JScript extensions document to justify that. Based on what I've seen, well, I have not seen evidence of any undrstanding of scope. I've seen complicated tool that, every time I have put it to the test, resulted in changed program behavior, and without warning. > Well I can't comment on that. There was a blog post from one of the > GMail team members where he talks about why they're using _private > members on simple objects instead of the module pattern. The main > point was the performance overhead of object creation if I remember > well. http://jsperf.com/closure-vs-member > 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> To summarize from that msg: I wrote a test to compare performance of the functions that:- 1) assign to global variable 2) read global variable 3) assign to local variable 4) read local variable: (requires first creating, then reading back). 5) assign to variable in enclosing function scope 6) reads value of var in enclosing scope 7) assign to global variable from nested scope 8) assign to global var from nested scope. 9) read global var from nested scope (part of Joel Webber's "closures" test). 10) set property of object in a closure 11) create a new object with properties | The purpose of tests 10 and 11 is to compare the speed of creating a | new object with reusing an existing one. Reusing an object will | result in the creation of fewer objects, so this should require less | memory. Will it be any faster? 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 as I summarized below: | Accessing properties of a shared Object will be somewhat fast. | Accessing local variables will also be fast, however local variables | can't be shared or reused unless they are passed around. If a | variable is reused, especially if the value of that variable is an | object, then recreating it each time is memory-inefficient. Storing | it in the containing scope will probably be a better alternative. CLosure can be used in such case to improve performance. 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> The takeaway from the "variables" thread, though, and the point I wanna drive home here is that variables should be declared where most appropriate. 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! When an object needs to be reused and it should also be private, then thje program should save it in an identifier in containing scope. > >> Running that example, comments and all, through CC at: >> http://closure-compiler.appspot.com/home >> >> The result is: >> | goog._secret="cannot be accessed directly from outside"; >> >> Identifier `_secret` can be accessed directly from outside. >> > > Where "outside" means any JS file other than the current one. > 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. -- 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]
