Another reason GC is sometimes surprisingly faster is not only you end up allocating less times like you mention, but because some GC are compacting garbage collectors and that simplyfies allocations dramatically because allocating memory is just increasing a pointer. Compare that to the way most C++ heaps get implemented. I don't know if that's the case with D's GC though. I completely understand what you say about the strings and who owns it, I've ran into the same situation a hundred times, not only with strings but with vectors, matrixes, lists, etc. After reading your post, I think I will have to revisit D sometime. I read about it a few years ago and I got the impression some syntax decisions had been made to ease the writing of the compiler as opposed to favoring the end user/programmer, but it's been a while and maybe I was too quick to judge. Steven "Walter Bright" <boost@xxxxxxxxxxxxxxx> wrote in message news:fbr2iv$ugg$1@xxxxxxxxxxxxxxxx > 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. > > ------ > Walter Bright > http://www.digitalmars.com C, C++, D programming language compilers > http://www.astoriaseminar.com Extraordinary C++ > - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
