6 ms·

Now it's been a bit since I last read about this a bit so forgive me if i'm off by a lot, but i'm pretty sure most javascript engines do this. The reasoning is

Now it's been a bit since I last read about this a bit so forgive me if i'm off by a lot, but i'm pretty sure most javascript engines do this. The reasoning is that they will parse the text slightly differently depending on if it is being inlined or not (potentially skipping steps if possible to speed the process up), so the heuristic needs to happen before the parsing step. Yeah, you could add in some checking to do things like strip comments, whitespace, and other "simple" things, but is it really worth the extra cycles? With minifiers and compilers in such large usage, a check like that would most likely just waste CPU time in the vast majority of cases, not to mention the extra developer time spent in the engine. That being said, i'm pretty sure this exact instance is a bug.

kazinator 10y ago
> parse the text slightly differently depending on if it is being inlined or not Any frosh should recognize that as a language design/implementation smell by their third year. > most javascript engines do this That somehow falls short of being convincing that it's right.
- Klathmon 10y ago
  You can say how it's design smell all you want, but do you have any reasons why? This is a JIT, optimizations like this can (and do) have some pretty big impacts on the speed of the execution without needing a long warmup which is extremely important for a language like javsacript. And in doing so it needs to balance battery usage, startup performance, "hot" performance, and a ton of other things. Its easy for you to stand back and say "that's dumb", but optimizations are often messy, and without them the language would run much slower. > That somehow falls short of being convincing that it's right. That's why I tried to provide other reasons why I think it's right...
- astrodust 10y ago
  The reason most JavaScript engines do it is because they have three or four ways of executing code that are all intended to offer maximal performance under different circumstances. If it takes longer to compile a function than to simply interpret it, don't bother compiling. If it's called frequently, compile it. Your academic view of compilers work has no bearing on how ugly and complicated reality is.
  - kazinator 10y ago
    > Your academic view of compilers work ... I didn't write anything about compilers. Scanning tokens isn't compiling. Even old line number BASIC in 1981 running on 1Mhz computers with 32Kb RAM at tokenized code as it was entered into memory.
    - astrodust 10y ago
      The JavaScript VM is a lot more complicated than a compiler, it's a compiler, an interpreter, and a whole heap of hacks to squeeze maximal performance out of it. That there's a problem processing whitespace isn't a reflection on the team not knowing their stuff, it's a problem that will be corrected. It's likely something that was never benchmarked and proven to be an issue before, or if it was an issue it was a low-priority one.
deleted 10y ago
[deleted]

kazinator 10y ago

> parse the text slightly differently depending on if it is being inlined or not Any frosh should recognize that as a language design/implementation smell by their third year. > most javascript engines do this That somehow falls short of being convincing that it's right.

Klathmon 10y ago
You can say how it's design smell all you want, but do you have any reasons why? This is a JIT, optimizations like this can (and do) have some pretty big impacts on the speed of the execution without needing a long warmup which is extremely important for a language like javsacript. And in doing so it needs to balance battery usage, startup performance, "hot" performance, and a ton of other things. Its easy for you to stand back and say "that's dumb", but optimizations are often messy, and without them the language would run much slower. > That somehow falls short of being convincing that it's right. That's why I tried to provide other reasons why I think it's right...
astrodust 10y ago
The reason most JavaScript engines do it is because they have three or four ways of executing code that are all intended to offer maximal performance under different circumstances. If it takes longer to compile a function than to simply interpret it, don't bother compiling. If it's called frequently, compile it. Your academic view of compilers work has no bearing on how ugly and complicated reality is.
- kazinator 10y ago
  > Your academic view of compilers work ... I didn't write anything about compilers. Scanning tokens isn't compiling. Even old line number BASIC in 1981 running on 1Mhz computers with 32Kb RAM at tokenized code as it was entered into memory.
  - astrodust 10y ago
    The JavaScript VM is a lot more complicated than a compiler, it's a compiler, an interpreter, and a whole heap of hacks to squeeze maximal performance out of it. That there's a problem processing whitespace isn't a reflection on the team not knowing their stuff, it's a problem that will be corrected. It's likely something that was never benchmarked and proven to be an issue before, or if it was an issue it was a low-priority one.

deleted 10y ago

[deleted]