On Monday, 12 May 2014 at 22:27:06 UTC, Kapps wrote:
because it's so short. This is quite sufficient for most
projects, but perhaps could be tweaked a bit more for certain
aspects like gaming, possibly even enabling concurrent
collection
for generation 0/1, but I'm not sure if this works well or is
feasible. Still, the important thing is to get a good general
one
to use first, like the default one .NET uses for workstation
applications.
I agree that getting a good (100% precise) GC is an important
first step. I am not so sure about generation based GC when you
have a window on a world map that you move around which roughly
is FIFO (first in, first out).
But to get good speed I think you are better off having multiple
pools that can be released with no collection when a
network-connection drops (if you have one conceptual pool per
connection), and optimized allocators that give you
pre-initialized objects etc.
In the ideal world all of this is transparent once you have
specified your memory model (in detail), so you only have to
issue a "new PlayerConnection" in the main logic of your program
and can tweak the memory handling elsewhere. That is not the D
way, from what I can tell from the forum posts so far, because
"new" is going to stay tied to one global GC heap. So you have to
write utility functions… which makes programs less legible.
