I should probably have said heap allocation rather than just allocation, because the alloca calls are the ones that would have the real benefit, those realtime applications are the reason I hope to be able to implement an async collection mode. If I were able to implement even a moderately compacting GC, I would be able to use a bump-the-pointer allocation strategy, which would be significantly faster than manual calls to malloc/free.
On 4/17/14, Regan Heath via Digitalmars-d <digitalmars-d@puremagic.com> wrote: > On Thu, 17 Apr 2014 14:08:29 +0100, Orvid King via Digitalmars-d > <digitalmars-d@puremagic.com> wrote: > >> I'm just going to put my 2-cents into this discussion, it's my >> personal opinion that while _allocations_ should be removed from >> phobos wherever possible, replacing GC usage with manual calls to >> malloc/free has no place in the standard library, as it's quite simply >> a mess that is really not needed, and quite simply, one should be >> figuring out how to simply not allocate at all rather than trying do >> do manual management. > > The standard library is a better place to put manual memory management > than user space because it should be done by experts, peer reviewed and > then would benefit everyone at no extra cost. > > There are likely a number of smaller GC allocations which could be > replaced by calls to alloca, simultaneously improving performance and > avoiding GC interaction. > > These calls could then be marked @nogc and used in the realtime sections > of applications without fear of collections stopping the world. > > Neither ARC nor a super amazing GC would be able to improve upon the > efficiency of this sort of change. > > Seems like win-win-win to me. > >> It is possible to implement a much better GC than what D currently >> has, and I intend to do exactly that when I have the time needed (in >> roughly a month). > > Excellent :) > > R >
