简体   繁体   中英

How does Closure Compiler work?

I am wondering that how Google's Closure Compiler works. Can I, for instance, make it convert function calls like:

if (MyApp.isArray(...)) {
    // foobar
}

to the actual implementation:

if ((typeof sthing === 'Object' && sthing.constructor.toString().indexOf("Array") !== -1))

I am asking this because I have a lot of wrappers that tie some functionality, and I would like Closure Compiler to convert them back to having one less function call.

Actually, does one extra function call make an app any more slower visibly?

Actually, does one extra function call make an app any more slower visibly?

Most likely not, but if you'd really like to know you just have to try your two different code examples and see if there's a difference. There are a lot of factors involved (your system, your browser, the function you're calling, etc) so a test is the way to go. I'd suggest Firebug for profiling.

The Closure Compiler (in Advanced mode) will in-line one-line functions, or functions that are called exactly once.

Apparently to the compiler writers, in the first case, it is more economical to save a function call, and one-line functions are usually short enough to be similar in length as the function call. In the second case, it avoids a function call and is shorter, so is a definite win.

It does not, as far as I know, in-line functions that are more than one line or called more than once. This is apparently to avoid code bloat.

I've heard of people saying that long one-liner functions are not in-lined, but I have always seen them in-lined.

I don't think there's anyway to have the Closure Compiler do that for you. It's main focus is to minify the source and as far as I can tell, it'll only inline function calls like that if it's actually shorter to do it.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM