12 ms·

Tabs slower than spaces in Firefox

179 points by emilong 10y ago

rosstex 10y ago
From the comments, it looks like there's an "optimization" that kicks in when a function is under 100 characters long. It seems that optimization is backfiring and actually making a tabbed function slower.
- kibwen 10y ago
  Interesting to note that character-based optimizations in JS engines are somewhat common (though this article is a few years old): http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...
- 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).
- dexterdog 10y ago
  Yes. If the optimization actually worked then tabs would be better than spaces in some cases and spaces would never out-perform tabs.
peterkelly 10y ago
I'm going to use this as fodder next time I get into an argument with someone about why spaces are better than tabs when writing code. Or maybe I've just been watching too much silicon valley...
- jasonm23 10y ago
  Tabs are the devils puss is a more convincing argument for the religiously motivated Tabs user. They don't respond to reason. Obviously. /s
- drewrv 10y ago
  I thought that was the most unrealistic thing this season: a supposedly genius programmer who loves tabs and hates spaces.
  - scrollaway 10y ago
    Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch/tabs https://leclan.ch/tabs)
    - yoavm 10y ago
      This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs? (I use spaces only because I try to follow common coding styles, like PEP 8, but I never gave it enough thought)
      - th0br0 10y ago
        Tab width can vary between editors, i.e. do a "set shiftwidth=8" in vim, and it'll be 8 spaces. Spaces are more constant.r
gnicholas 10y ago
Read the title and thought it had to do with tabbed browsing versus using different Spaces in OS X.
deleted 10y ago
[deleted]
db48x 10y ago
This is great bug, right up there with the Dwarf Fortress bug that involved a dwarf planting a bed in a farm plot.
- Daneel_ 10y ago
  Would you be able to link this? I'm interested in reading about it. A quick google for 'dwarf planting a bed in a farm plot bug fortress' turns up nothing relevant at a glance.
  - timv 10y ago
    It's mentioned in the wikipedia page under "further updates" https://en.wikipedia.org/wiki/Dwarf_Fortress#Further_updates https://en.wikipedia.org/wiki/Dwarf_Fortress#Further_updates Which refers to a brief mention here: http://www.pcgamer.com/community-heroes-tarn-adams-for-dwarf-fortress/2/ http://www.pcgamer.com/community-heroes-tarn-adams-for-dwarf... but there are no details.
deleted 10y ago
[deleted]
mk3 10y ago
This reminds me of "Silicon Valley" episode whent there was TABS vs. SPACES fight :)
Gonzih 10y ago
Tested in ff 47 on linux, same result in both cases (0). Am I missing here something?
- 1_player 10y ago
  Same on Firefox 47.0.1, OS X -- maybe it's only on Windows? BTW I get ~15ms on Safari, ~60ms on Chrome and ~47ms on Firefox.
kazinator 10y ago
Anyone who makes a language in which the performance of a call to previously processed code depends on its original whitespace should immediately be stripped of their CS degree, if they even have one. If some decision depends on the size of a function, that size should be measured over the parsed code: number of nodes in the abstract syntax tree or whatever. This should be obvious to everyone by around the end of their second year of school. A function isn't larger if we give it wider indentation with more spaces, or replace its local variables with ones having longer names.
- Klathmon 10y ago
  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...
Jean-Philipe 10y ago
Now, can we please have a bug that punishes the use of semicolons?
- skykooler 10y ago
  That would be terrible for minified code, though
  - Klathmon 10y ago
    well a newline is the same amount of bytes!
    - skykooler 10y ago
      Newlines and semicolons aren't always interchangeable in Javascript.
      - Klathmon 10y ago
        the only situation they aren't is when a line starts with a [ or a ( In every other scenario, a newline and a semicolon are interchangeable.
- Sir_Cmpwn 10y ago
  I vote for a bug that punishes the opposite.
  - NTripleOne 10y ago
    Hear, hear.
- carterehsmith 10y ago
  Man, you are about to start WWIII :) https://news.ycombinator.com/item?id=3842713 https://news.ycombinator.com/item?id=3842713

179 points by emilong 10y ago

From the comments, it looks like there's an "optimization" that kicks in when a function is under 100 characters long. It seems that optimization is backfiring and actually making a tabbed function slower.

kibwen 10y ago
Interesting to note that character-based optimizations in JS engines are somewhat common (though this article is a few years old): http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-optimizing-compiler http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...
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).
dexterdog 10y ago
Yes. If the optimization actually worked then tabs would be better than spaces in some cases and spaces would never out-perform tabs.

peterkelly 10y ago

I'm going to use this as fodder next time I get into an argument with someone about why spaces are better than tabs when writing code. Or maybe I've just been watching too much silicon valley...

jasonm23 10y ago
Tabs are the devils puss is a more convincing argument for the religiously motivated Tabs user. They don't respond to reason. Obviously. /s
drewrv 10y ago
I thought that was the most unrealistic thing this season: a supposedly genius programmer who loves tabs and hates spaces.
- scrollaway 10y ago
  Poe's law and all, I hope your comment isn't serious. The whole point was to highlight Richard's "neurotic" side. (It failed to convey it for me when his girlfriend started audibly indenting by hitting the spacebar 8 times... I'd go nuts, who wouldn't?) Also, plenty of geniuses use tabs :) the Linux kernel included. It obviously has no relation. (Seriously though, tabs are a matter of accessibility. https://leclan.ch/tabs https://leclan.ch/tabs)
  - yoavm 10y ago
    This is interesting. Why do we use spaces anyway? I mean, really - what are the advantages spaces have over tabs? (I use spaces only because I try to follow common coding styles, like PEP 8, but I never gave it enough thought)
    - th0br0 10y ago
      Tab width can vary between editors, i.e. do a "set shiftwidth=8" in vim, and it'll be 8 spaces. Spaces are more constant.r

gnicholas 10y ago

Read the title and thought it had to do with tabbed browsing versus using different Spaces in OS X.

deleted 10y ago

[deleted]

db48x 10y ago

This is great bug, right up there with the Dwarf Fortress bug that involved a dwarf planting a bed in a farm plot.

Daneel_ 10y ago
Would you be able to link this? I'm interested in reading about it. A quick google for 'dwarf planting a bed in a farm plot bug fortress' turns up nothing relevant at a glance.
- timv 10y ago
  It's mentioned in the wikipedia page under "further updates" https://en.wikipedia.org/wiki/Dwarf_Fortress#Further_updates https://en.wikipedia.org/wiki/Dwarf_Fortress#Further_updates Which refers to a brief mention here: http://www.pcgamer.com/community-heroes-tarn-adams-for-dwarf-fortress/2/ http://www.pcgamer.com/community-heroes-tarn-adams-for-dwarf... but there are no details.

deleted 10y ago

[deleted]

mk3 10y ago

This reminds me of "Silicon Valley" episode whent there was TABS vs. SPACES fight :)

Gonzih 10y ago

Tested in ff 47 on linux, same result in both cases (0). Am I missing here something?

1_player 10y ago
Same on Firefox 47.0.1, OS X -- maybe it's only on Windows? BTW I get ~15ms on Safari, ~60ms on Chrome and ~47ms on Firefox.

kazinator 10y ago

Anyone who makes a language in which the performance of a call to previously processed code depends on its original whitespace should immediately be stripped of their CS degree, if they even have one. If some decision depends on the size of a function, that size should be measured over the parsed code: number of nodes in the abstract syntax tree or whatever. This should be obvious to everyone by around the end of their second year of school. A function isn't larger if we give it wider indentation with more spaces, or replace its local variables with ones having longer names.

Klathmon 10y ago
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...

Jean-Philipe 10y ago

Now, can we please have a bug that punishes the use of semicolons?

skykooler 10y ago
That would be terrible for minified code, though
- Klathmon 10y ago
  well a newline is the same amount of bytes!
  - skykooler 10y ago
    Newlines and semicolons aren't always interchangeable in Javascript.
    - Klathmon 10y ago
      the only situation they aren't is when a line starts with a [ or a ( In every other scenario, a newline and a semicolon are interchangeable.
Sir_Cmpwn 10y ago
I vote for a bug that punishes the opposite.
- NTripleOne 10y ago
  Hear, hear.
carterehsmith 10y ago
Man, you are about to start WWIII :) https://news.ycombinator.com/item?id=3842713 https://news.ycombinator.com/item?id=3842713