Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.

> Wincent Colaiuta wrote:
>> Git is all about speed, and C is the best choice for speed,  
>> especially in context of Git's workload.
>
> I can appreciate that. I originally got into writing compilers  
> because my game (Empire) ran too slowly and I thought the existing  
> compilers could be dramatically improved.
>
> And technically, yes, you can write code in C that is >= the speed  
> of any other language (other than asm). But practically, this isn't  
> necessarily so, for the following reasons:
>
> 1) You wind up having to implement the complex, dirty details of  
> things yourself. The consequences of this are:
>
>    a) you pick a simpler algorithm (which is likely less efficient  
> - I run across bubble sorts all the time in code)
>
>    b) once you implement, tune, and squeeze all the bugs out of  
> those complex, dirty details, you're reluctant to change it. You're  
> reluctant to try a different algorithm to see if it's faster. I've  
> seen this effect a lot in my own code. (I translated a large body  
> of my own C++ code that I'd spent months tuning to D, and quickly  
> managed to get significantly more speed out of it, because it was  
> much simpler to try out different algorithms/data structures.)

> 2) Garbage collection has an interesting and counterintuitive  
> consequence. If you compare n malloc/free's with n gcnew/ 
> collections, the malloc/free will come out faster, and you conclude  
> that gc is slow. But that misses one huge speed advantage of gc -  
> you can do FAR fewer allocations! For example, I've done a lot of  
> string manipulating programs in C. The basic problem is keeping  
> track of who owns each string. This is done by, when in doubt, make  
> a copy of the string.
>
> But if you have gc, you don't worry about who owns the string. You  
> just make another pointer to it. D takes this a step further with  
> the concept of array slicing, where one creates windows on existing  
> arrays, or windows on windows on windows, and no allocations are  
> ever done. It's just pointer fiddling.