@inline JSDoc built-in support

[polkovn...@gmail.com]

I've been looking for a way to instruct Compiler to inline functions unconditionally. There's a repo with a very slight modifications to allow this (https://github.com/bramstein/closure-compiler-inline/commit/d74a3ed32edad72e28b62aa20863fd1f4c0758db). Why this code wasn't pulled into main repo? Will it be ever pulled?

[Nick Santos]

To the first question: i don't believe anyone has ever asked it to be
pulled? I didn't even know about that repo until you pointed it out.

To the second question: This comes up every once in a while, but our
position has been that 'inline' annotations are silly. In shared code,
why does the declaration get to decide whether the function is inlined
for all call sites?

re: ' inline functions unconditionally': out of curiosity, are there
any C/C++ compilers at all that guarantee 'unconditional inlining'?
From http://clang.llvm.org/compatibility.html#inline
"The inline keyword is not required for a function to be inlined, nor
does it guarantee that it will be. Some compilers ignore it
completely. Clang treats it as a mild suggestion from the programmer."

[polkovn...@gmail.com]

To the first question: i don't believe anyone has ever asked it to be 
pulled? I didn't even know about that repo until you pointed it out. 

I'm pretty sure that's not the only repo with such modifications, so I've asked as if authors knew about it. Sorry.

This comes up every once in a while, but our 
position has been that 'inline' annotations are silly. In shared code, 
why does the declaration get to decide whether the function is inlined 
for all call sites? 

Currently, I'm build a library for parsing expression grammars in JS. Declarations like

b.par(b.flat(b.seq(b.ref(expr1), b.ref(op0), b.ref(expr0)), function (a, b, c) {...}), b.ref(expr1))

are essentially a bunch of whiles and ifs. If these calls are not inlined, performance degrades a lot due to a number of function calls per each character of input. There's absolutely no reason for the end user of parser built on top of this library and compiled with Closure to wish these functions not to be inlined.

re: ' inline functions unconditionally': out of curiosity, are there 
any C/C++ compilers at all that guarantee 'unconditional inlining'? 

__forceinline in Visual Studio should do so. The problem with inline is that in complex code with recursion there's no way for the compiler to understand, whether it's possible to inline a function, or it will keep inlining eternally. Comparison to C++ is a bit biased, because there's no such thing as (Turing complete) template metaprogramming in JS.

вторник, 17 июня 2014 г., 18:21:40 UTC+4 пользователь nick santos написал:

[Nick Santos]

yes, the comparison to C++ is a bit biased. But it may be biased in
the other direction: JS has a JIT that can inline things at runtime,
so the advantages of inlining things at compile-time for runtime
performance is less clear.

you wrote:
"If these calls are not inlined, performance degrades a lot due to a
number of function calls per each character of input."

are you sure? most modern JITs seem to be very good about inlining
this sort of thing. if you're seeing perf degrade a lot, then maybe
you're running into a V8 bug that should be fixed?

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "Closure Compiler Discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to closure-compiler-d...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/closure-compiler-discuss/4856fe94-c38f-4bad-af9e-1e4e3349a6d2%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.

[polkovn...@gmail.com]

There's a PEG.js by David Majda that generates while/if code intentionally. JIT has its limits.

• Code optimization is an undecidable problem. There's always a trade-off between JIT optimization time and run time of the script.
• JIT is in no way a part of JS standard.
• Parsers are quite unlike the normal JS code due to highly increased cyclomatic complexity, so one shouldn't expect JIT to perform well on parsers.

I'll post a jsperf comparison to PEG.js when the library gets into somewhat better state. Anyway, I don't see any reasons in restricting @inline.

вторник, 17 июня 2014 г., 18:47:22 UTC+4 пользователь nick santos написал:

[Si Robertson]

Inlining/expansion is something that should be determined and dealt with by a compiler or virtual machine. Having annotations or keywords in source code that attempt to force inlining is completely unnecessary.

Just my opinion of course :-)

[John Lenz]

Can you provide an provide a code sample for code that doesn't get inlined?   If it never gets inlined now it may be that the compiler couldn't inline it even if you told it to ALWAY inline (it doesn't know for sure what the definition is, the method contains expressions that it doesn't know how to rewrite (like recursion)).  It maybe that a small change in how you write your code would be sufficient.

On Tue, Jun 17, 2014 at 10:23 AM, Si Robertson <retrom...@gmail.com> wrote:

Inlining/expansion is something that should be determined and dealt with by a compiler or virtual machine. Having annotations or keywords in source code that attempt to force inlining is completely unnecessary.

Just my opinion of course :-)

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/6bf1e0ae-0788-4f59-8dd5-4577c672d247%40googlegroups.com.

[Si Robertson]

John, did you mean to reply to my comment?

I'm not having any inlining related issues with the compiler myself; if the compiler decides it cannot inline something for one reason or another I'm perfectly happy with that decision.

On Tuesday, 17 June 2014 21:39:51 UTC+1, John wrote:

Can you provide an provide a code sample for code that doesn't get inlined?   If it never gets inlined now it may be that the compiler couldn't inline it even if you told it to ALWAY inline (it doesn't know for sure what the definition is, the method contains expressions that it doesn't know how to rewrite (like recursion)).  It maybe that a small change in how you write your code would be sufficient.

On Tue, Jun 17, 2014 at 10:23 AM, Si Robertson <retrom...@gmail.com> wrote:

Inlining/expansion is something that should be determined and dealt with by a compiler or virtual machine. Having annotations or keywords in source code that attempt to force inlining is completely unnecessary.

Just my opinion of course :-)

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-discuss+unsub...@googlegroups.com.

[John Lenz]

no, the thread in general.

To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/ad64d12c-d65b-472d-8011-df275a9c65af%40googlegroups.com.

[pauld...@gmail.com]

As much as I hate microbenchmarks, I made one: http://jsperf.com/inline2. No difference.

Sometimes inlining can make things slower.

The conclusion of the example in the 2013 Google I/O session Accelerating Oz with V8: Follow the Yellow Brick Road to JavaScript Performance was that V8 couldn't optimize all parts of the function, so they split part of it out into a function it could optimize.

The only languages I've used with inline are C/C++. It's not terrible. The only bad thing about is that people use it (for no good reason...just cause they like thinking their code is fast).

[Tyler Breisacher]

> The only bad thing about is that people use it

I don't understand what you mean. If "people using it" is a bad thing (and I would probably agree it is) then how is `inline` a good thing at all? Isn't it just visual noise?

--

---
You received this message because you are subscribed to the Google Groups "Closure Compiler Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to closure-compiler-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/closure-compiler-discuss/b74283d6-582f-4e15-8025-bcc400d5bad4%40googlegroups.com.