
Tabs slower than spaces in Firefox - emilong
https://bugzilla.mozilla.org/show_bug.cgi?id=1154339
======
peterkelly
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...

~~~
drewrv
I thought that was the most unrealistic thing this season: a supposedly genius
programmer who loves tabs and hates spaces.

~~~
scrollaway
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
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)

~~~
scrollaway
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 lines just because you introduced a variable one character
longer than the others. Irrelevant, though; such alignment is perfectly fine
to do with spaces in a context where you indent with tabs.

The other type of alignment is beginning-of-line alignment, which is indeed
not doable with spaces. Some people recommend doing such alignment with spaces
despite the tab indent (cf.
[http://dmitryfrank.com/articles/indent_with_tabs_align_with_...](http://dmitryfrank.com/articles/indent_with_tabs_align_with_spaces)).
It's a valid argument but I feel it's too much of an aberration to be taken
seriously.

I personally find such alignment generally repulsive anyway. Take a look at
the following code and tell me which method looks better:

[http://sprunge.us/ZFHJ](http://sprunge.us/ZFHJ)

Too many times have I seen such function calls where the space between the
parenthese and the soft wrap leaves <10 characters to work with. And here we
go with one small argument per line, every argument preceded by 70+ spaces. I
know programmers who could fit video games in the bytes used for just a single
function call like that.

~~~
Stratoscope
Indeed, column alignment is just about the only reason to prefer spaces for
indentation. If you use column alignment, then indenting with spaces avoids
the question of "tabs for indentation, spaces for alignment."

But I'm with you: that kind of column alignment is harmful to maintainability,
and I find it much less readable too.

Some time ago I posted a few examples of column alignment gone bad, from the
Servo source code:

[https://news.ycombinator.com/item?id=9469713](https://news.ycombinator.com/item?id=9469713)

and also discussed alignment here:

[https://news.ycombinator.com/item?id=9469713](https://news.ycombinator.com/item?id=9469713)

Once you give up column alignment, there's no longer any real reason to prefer
spaces, and you can gain the benefits of using tabs. As a side benefit, when
you give up alignment, your code becomes just as readable in a proportional
font as a monospaced font.

More details in my previous comments linked above, so I won't rehash them
here. :-)

~~~
scrollaway
Hah, those are beautiful examples, thank you! :) The latest I encountered was
a few days ago in the allauth codebase, where I found several instances of
things like these: [https://github.com/pennersr/django-
allauth/blob/07d70fd68c4c...](https://github.com/pennersr/django-
allauth/blob/07d70fd68c4cb87b8eb4770952a029d8c72db392/allauth/account/views.py#L621-L624)

I remember that page, actually. It's a really good point that code alignment
breaks proportional fonts, I never considered it. More points for
accessibility I suppose!

------
rosstex
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.

~~~
Sylos
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
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
> _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
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.

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

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

~~~
Daneel_
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
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...](http://www.pcgamer.com/community-heroes-tarn-adams-for-dwarf-
fortress/2/)

but there are no details.

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

~~~
1_player
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.

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

~~~
Sir_Cmpwn
I vote for a bug that punishes the opposite.

~~~
NTripleOne
Hear, hear.

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

------
kazinator
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
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
> _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.

~~~
astrodust
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
> _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
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.

