Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tabs slower than spaces in Firefox

bugzilla.mozilla.org

Post reply on HN
Print view View original

41–50 of 129 posts

Re: Tabs slower than spaces in Firefox

#41

Post by girvo »

andrewfong wrote: post #38
yoavm wrote: post #15

Earlier quoted context omitted.

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)

How do tab advocates deal with max column widths? Many projects require that lines not exceed 80 chars, but I'm not sure how'd you establish that kind of limit with variable length tabs.

EditorConfig or various other configuration setups allow your editor/git/whatever to read a tab as if it is "n" spaces, where that is somewhat configurable. Using EditorConfig, this allows consistency across tooling, and solves this problem neatly (at least in this particular use-case, YMMV in other places where this isn't possible or desirable).

Re: Tabs slower than spaces in Firefox

#42

Post by girvo »

albertzeyer wrote: post #20
Sylos wrote: post #11

Earlier quoted context omitted.

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.

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.

> 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 ;)

Re: Tabs slower than spaces in Firefox

#43

Post by Stratoscope »

yAnonymous wrote: post #40
Stratoscope wrote: post #36

Earlier quoted context omitted.

The problem there isn't tabs, it's column alignment. If you stop using alignment and use only indentation for your multiline statements, these issues go away. Your code will be just as readable with any tab size, and even in a proportional font. And your line lengths get much shorter in the process. For specific examples, see the other comments in this thread from scrollaway and myself, in particular the Servo source…

So you're trying to dictate a coding style to make up for tabs' weaknesses? That's like Apple's reaction to bad reception on phones: "You're holding it wrong". No, thanks, I'd rather use spaces that don't require any workarounds.

> So you're trying to dictate a coding style to make up for tabs' weaknesses?

Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces.

I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment.

Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it's unfriendly toward source control diffs, it's fiddly to maintain, it mandates the use of a monospaced font, and I find that it harms readability compared to the alternative of using indentation.

Take a look at the Servo code examples I linked to in another comment. Are the column-aligned versions a better way to format code than the indented versions?

Here's another way to look at it. If the column-aligned way of writing a multiline function call or expression is such a good thing, why don't we also format blocks of statements this way:

  if( foo == bar ) { if( baz == moo ) { console.log( "yes" );
                                        this.that = true; }
                     else { console.log( "no" );
                            this.that = false; } }
instead of:

  if( foo == bar ) {
      if( baz == moo ) {
          console.log( "yes" );
          this.that = true;
      } else {
          console.log( "no" );
          this.that = false;
      }
  }
It is probably obvious that I prefer the latter, as would most developers. So why not apply the same formatting principle to expressions that we apply to statements?

Re: Tabs slower than spaces in Firefox

#44

Post by efaref »

yoavm wrote: post #15
scrollaway wrote: post #14

Earlier quoted context omitted.

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…

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)

Tabs make no sense to me as they're clearly control codes.

I maintain that if tabs are permitted, so are other ASCII control codes, like vertical tab, form feed (which is actually used in GNU code), and bell.

    int foo(void)
    {
    /*  This bit is really important. */
    ...
    }
    
    int blah(void)
    {
    ...
    }
:-)

Re: Tabs slower than spaces in Firefox

#45

Post by diggan »

girvo wrote: post #42
albertzeyer wrote: post #20

Earlier quoted context omitted.

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.

> 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 ;)

I think you're thinking about "Optimization killers" (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.

Re: Tabs slower than spaces in Firefox

#46

Post by piaste »

scrollaway wrote: post #19
yoavm wrote: post #15

Earlier quoted context omitted.

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)

One of the main drivers for spaces is alignment, which you should never attempt to do with tabs (except in contexts which normalize tabstops, which generally excludes programming). Aligning within a line can and should be done with spaces. There's good reasons against alignment in such cases -- for example, it creates git blame/git diff noise when reformatting due to having to update alignment on a bunch of other lin…

for example, it creates git blame/git diff noise when reformatting due to having to update alignment on a bunch of other lines just because you introduced a variable one character longer than the others.

If you're working with git on a non-whitespace-sensitive language, and this annoys you, you can use the --ignore-space-change option to avoid this.

Re: Tabs slower than spaces in Firefox

#47

Post by yAnonymous »

Stratoscope wrote: post #43
yAnonymous wrote: post #40

Earlier quoted context omitted.

So you're trying to dictate a coding style to make up for tabs' weaknesses? That's like Apple's reaction to bad reception on phones: "You're holding it wrong". No, thanks, I'd rather use spaces that don't require any workarounds.

> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it…

"Many of us" - you are using that way too often in your posts and it's a pseudo argument. Fact is, you're giving up the choice of different coding styles to make something broken work.

"Many of us" prefer spaces for that reason and that's why it has become the de facto standard.

Re: Tabs slower than spaces in Firefox

#48

Post by Stratoscope »

yAnonymous wrote: post #47
Stratoscope wrote: post #43

Earlier quoted context omitted.

> So you're trying to dictate a coding style to make up for tabs' weaknesses? Not in the slightest. The disadvantages of column alignment have nothing to do with whether you use tabs or spaces. I don't recall for sure, but I think I was using spaces for indentation at the time that I stopped using column alignment. Column alignment has the same problems if you indent with spaces: it leads to excessive line length, it…

"Many of us" - you are using that way too often in your posts and it's a pseudo argument. Fact is, you're giving up the choice of different coding styles to make something broken work. "Many of us" prefer spaces for that reason and that's why it has become the de facto standard.

Your point about my overuse of "many of us" is a good one, so I changed it to "I" in the comment you just replied to. Fair enough?

But look, my real point here is that column alignment is detrimental in several ways, and indentation is a better way to illustrate your code structure - both for statements and expressions.

Using indentation instead of column alignment isn't a workaround for anything - it's just a more practical, readable, maintainable way to format your code. This question really has nothing to do with tabs or spaces.

Re: Tabs slower than spaces in Firefox

#50

Post by saucetenuto »

girvo wrote: post #41
andrewfong wrote: post #38

Earlier quoted context omitted.

How do tab advocates deal with max column widths? Many projects require that lines not exceed 80 chars, but I'm not sure how'd you establish that kind of limit with variable length tabs.

EditorConfig or various other configuration setups allow your editor/git/whatever to read a tab as if it is "n" spaces, where that is somewhat configurable. Using EditorConfig, this allows consistency across tooling, and solves this problem neatly (at least in this particular use-case, YMMV in other places where this isn't possible or desirable).

Suppose I have a configured tab width of 2 and I write a line with three tabs that's 78 characters wide. When my friend with tab-width 8 views it, he'll see a line that's 90 characters wide. What do projects with 80 character limits do in situations like that?

In either case the line contains only 75 characters, of course, but that's a pretty pedantic non-answer: we care about horizontal screen space, not the number of bytes of storage you'd need.

Post reply on HN