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

91–100 of 129 posts

Re: Tabs slower than spaces in Firefox

#91

Post by sevensor »

scrollaway wrote: post #14
drewrv wrote: post #10

Earlier quoted context omitted.

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

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…

> hitting the spacebar 8 times

I used to do this before I switched from vi to vim. I used 2-space indents to save wear and tear on my thumb.

Re: Tabs slower than spaces in Firefox

#92

Post by d0lph »

Confiks wrote: post #81
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…

> 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? I remember when I got into coding Runescape autoclick bots when I was 14, in an arcane Delphi editor / standard library called SCAR, it was the insane convention to not use any indenting at all. Indeed you had to manually hit the spacebar again and again to get some proper indent…

If you're interested, that community is still alive and pretty active as SIMBA [1].

Not hard to find very smart people with very poor coding standards.

[1] https://villavu.com/forum/

Re: Tabs slower than spaces in Firefox

#93

Post by d0lph »

js2 wrote: post #71
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…

If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board. But what happens in practice is that the file ends up with a mish-mash of tabs and spaces throughout and the file is only legible if you set your tab stop to a specific setting, and sometimes not even then because different authors have used different tab stops for both indentation and alignment. At whic…

I think it would not be hard to create a git hook that checked and fixed inconsistent tabbing.

As someone who tabs, 4 is a very common standard, and consistency has never been a problem.

Re: Tabs slower than spaces in Firefox

#95

Post by kannanvijayan »

Sylos wrote: post #11
rosstex wrote: post #2

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.

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.

(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).

Re: Tabs slower than spaces in Firefox

#96

Post by chriswarbo »

scrollaway wrote: post #83
chriswarbo wrote: post #69

Earlier quoted context omitted.

> Take a look at the following code and tell me which method looks better: That seems like a strawman to me. I would go with something like: function() { nested_code() { some_very_long_function_call( long_argument_one, long_argument_two, long_argument_three, long_argument_four, ); } }

That is no semantically no different to #2 so I'm not sure why you think it's a strawman seeing as you just agreed with me. While, like I said, there's reasons against alignment within lines, using tabs doesn't prevent you from doing it.

I meant that aligning columns is orthogonal to breaking up long lines; you can do either, both, or neither, so your example comes across as a strawman.

Re: Tabs slower than spaces in Firefox

#97

Post by frandroid »

d0lph wrote: post #93
js2 wrote: post #71

Earlier quoted context omitted.

If the tab people would reliably use tab for leading indent and space for further alignment, I'd be 100% on board. But what happens in practice is that the file ends up with a mish-mash of tabs and spaces throughout and the file is only legible if you set your tab stop to a specific setting, and sometimes not even then because different authors have used different tab stops for both indentation and alignment. At whic…

I think it would not be hard to create a git hook that checked and fixed inconsistent tabbing. As someone who tabs, 4 is a very common standard, and consistency has never been a problem.

In our project, we use ESlint to check for this kind of stuff. For a while we had it forcibly fix indentation and minor bugs but some devs didn't like it so now it just warns you. I thought it was amazing.

Re: Tabs slower than spaces in Firefox

#100

Post by astrodust »

kazinator wrote: post #87
Klathmon wrote: post #77

Earlier quoted context omitted.

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…

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

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.

Post reply on HN