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

El 7/9/2007, a las 10:36, Walter Bright escribió:

Wincent Colaiuta wrote:

quoted

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

While I accept that this is generally true, I think Git is somewhat  
of a special case. From a design perspective the data structures and  
algorithms are remarkably simple -- therein lies its elegance. I  
think it's precisely the kind of problem that can be tackled well  
with a close-to-the-metal language like C.

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.

This mirrors my experience in desktop application development.  
Despite GC being "slower" the app actually runs faster and a lot of  
nasty problems (shared resources, locking etc) just magically go  
away. Development is easier too.

But once again I think Git falls into a special category where the  
design makes the "hassle" of developing in C worth it.

Wincent