Faster Virtual Method Dispatch

[kris]

Craig Black wrote:
>>The nice thing about D, as a language, is that it supports both 
>>approaches. The bad thing, for your needs, is that phobos is tightly bound 
>>to the GC. My particular gripes are with the GC activity caused via utf 
>>conversions, std.string and so on. There's a surprising, perhaps 
>>troublesome, amount of GC activity generated from within phobos itself. 
>>This is one of the reasons alternative libraries exist.
> 
> 
> Correct.  But since the language core relies on Phobos I don't think that 
> there is a reasonable way to completely decouple D from GC.  To me this 
> situation is quite ugly.  It would be nice if there was a way to replace 
> Phobos completely.


That's really quite easy, Craig; start with Ares, and then apply 
whatever you need on top. For example, Ares and Mango go together really 
well, and both make a point about not allocating memory where there's a 
sensible alternative. In fact, the Mango HttpServer does not touch the 
GC even once per service request, once it warms up -- all hail to the 
groovy array-slice, and behold the power of the trout-slap :)

(kudos to IRC #d)

There again, I suspect fear of the GC is somewhat overplayed; although 
it certainly troubles me when it is abused. Thus, it doesn't bother me 
at all that Ares kinda' needs a GC also. Perhaps it's more a question of 
libraries, and code in general, treating it with a little respect :)

After all, using any kind of malloc() should perhaps be a question-mark 
for high-performance code

- Kris