Re: On Tabs and Spaces

On Wed, 17 Oct 2007, Jeff King wrote:

Yes. 

You're missing the fact that some people have problems with editors.

So they add a line, and they add *that* line with the wrong kind of indentation. And it shows up among the other lines like this (here the whole patch is indented):

	diff --git a/kernel/sched.c b/kernel/sched.c
	index 92721d1..1ecb164 100644
	--- a/kernel/sched.c
	+++ b/kernel/sched.c
	@@ -127,6 +127,7 @@ static inline u32 sg_div_cpu_power(const struct sched_group *sg, u32 load)
	 static inline void sg_inc_cpu_power(struct sched_group *sg, u32 val)
	 {
	 	sg->__cpu_power += val;
	+        wrong indentation here.
	 	sg->reciprocal_cpu_power = reciprocal_value(sg->__cpu_power);
	 }
	 #endif

and so you see the fact that somebody messed up in the patch itself.

It actually more often goes the other way: somebody may have messed up earlier, but did so *consistently* so it wasn't obvious when looking at the patch. And then somebody fixes one line, and now that one fixed line is indented correctly but differently.

When it gets *too* bad, we just reindent the whole file, but more commonly when I notice it in a diff, I just edit that particular region or even just the diff itself in-place.

Generally, it seldom comes to even that. Doing a

	git grep '        ' -- '*.c'

(that's now eight spaces) returns quite a lot of lines, and it's generally not worth worrying about (not all of them are indentation - people do use spaces for lining things up etc - but a lot of it really is just indents done against the coding style).

I didn't even time it, and I called it at 20% without even counting any tabs. Why? Because it's inevitable!

It so happens that "grep" has a lot of really clever heuristics, so that it is actually better at passing over characters that it knows cannot start the pattern you are searching for, so timing "grep" is actually quite complex in the general case. So I bet that if you had grepped for something that started with a space, you'd probably have found a bigger slowdown.

But ignore all that complexity, and it really boils down to a really simple principle: bigger data sets are more expensive, and "linear slowdown" is actually almost the best possible case. Quite often, a bigger data set causes *worse* than a linear slowdown.

It's very seldom the case that you grow some problem space and performance stays the same.

Well, performance analysis isn't exactly a "waste". That "git grep" was something we spent some time trying to go fast (for example, doing the whole external grep tool thing because that thing is usually optimized to h*ll and back - so the execve() overhead is more than worth it).

And it's a real workload. Maybe others don't use "git grep" quite as much as I do, but I do it *all* the time. Some other people probably use ctags or something, I personally prefer just a fast git grep.

But the *exact* same issues will show up for "simple" things like "git bisect". One of the biggest costs of git bisect is actually checking out the source tree. If the source tree is on the order of 20% larger, what does that mean?

So it doesn't matter if you have a terabyte disk. Source code size *still* matters.

And 20% (or 16%) is more than a lot of other optimizations can help you save!

Yeah, I don't think it's wonderful, but it might even be a good thing as a "hey, at least you are aware of the notion of GC now" kind of introduction to people (who then hopefully realize that they don't actually want automatic GC, but rather do it once a week or something).

		Linus