4 ms·

Obvious fix: Count the length of the function without whitespace characters, so that both versions are equally slowed down by the optimization. Unfortunately,

by Sylos 10y ago

Obvious fix: Count the length of the function without whitespace characters, so that both versions are equally slowed down by the optimization. Unfortunately, this sounds like one of those problems where a non-fix like that is still the best you can really do. If nothing else, this should still be at least a more accurate representation of the complexity of the function.

albertzeyer 10y ago
Then the next guy comes and complains why `var a = 42` is slower than `var abc = 42`. And so on. I wonder if it also counts comments. It soon becomes quite complicated. Maybe you can count the number of dots in non-comments and non-strings and will get a better heuristic.
- girvo 10y ago
  > I wonder if it also counts comments. It does! If I remember correctly, there's a great gist floating around that shows this off, where the comment itself is what caused two functions to be different in performance, despite being identical ;)
  - diggan 10y ago
    I think you're thinking about "Optimization killers" (https://news.ycombinator.com/item?id=7943303 https://news.ycombinator.com/item?id=7943303 [which funnily, I submitted 754 days ago!]), but it just touches V8. Haven't seen one around for SpiderMonkey, would be interested in seeing one though.
kannanvijayan 10y ago
(Note: I worked on SpiderMonkey's JIT and various optimization-related things) In general the accepted "best practice" approach is always to use the length of the compiled bytecode as a heuristic. This is what we use basically everywhere in the JIT for "function size" heuristics - inlining logic being the biggest user. V8 doesn't have a bytecode (although I've heard they're adding a bytecode interpreter now), but even there, they can use AST-weight (i.e. the count of all vertices in the AST for a function) as a measure of the function size. Counting bytes, characters, or any sort of raw source-related metric is a bad idea. These things happen because it's easy to use an easy heuristic that'll work most of the time. The size of a function in source-code bytes is easy to get, and always available. You may not be able to guarantee that bytecode or AST info is available when you want to use it (e.g. if the function has been lazified due to lack-of-use and all the compiled bits thrown away).

by Sylos 10y ago

albertzeyer 10y ago

Then the next guy comes and complains why `var a = 42` is slower than `var abc = 42`. And so on. I wonder if it also counts comments. It soon becomes quite complicated. Maybe you can count the number of dots in non-comments and non-strings and will get a better heuristic.

girvo 10y ago
> I wonder if it also counts comments. It does! If I remember correctly, there's a great gist floating around that shows this off, where the comment itself is what caused two functions to be different in performance, despite being identical ;)
- diggan 10y ago
  I think you're thinking about "Optimization killers" (https://news.ycombinator.com/item?id=7943303 https://news.ycombinator.com/item?id=7943303 [which funnily, I submitted 754 days ago!]), but it just touches V8. Haven't seen one around for SpiderMonkey, would be interested in seeing one though.

kannanvijayan 10y ago

(Note: I worked on SpiderMonkey's JIT and various optimization-related things) In general the accepted "best practice" approach is always to use the length of the compiled bytecode as a heuristic. This is what we use basically everywhere in the JIT for "function size" heuristics - inlining logic being the biggest user. V8 doesn't have a bytecode (although I've heard they're adding a bytecode interpreter now), but even there, they can use AST-weight (i.e. the count of all vertices in the AST for a function) as a measure of the function size. Counting bytes, characters, or any sort of raw source-related metric is a bad idea. These things happen because it's easy to use an easy heuristic that'll work most of the time. The size of a function in source-code bytes is easy to get, and always available. You may not be able to guarantee that bytecode or AST info is available when you want to use it (e.g. if the function has been lazified due to lack-of-use and all the compiled bits thrown away).