On Monday, 14 September 2015 at 00:41:28 UTC, Jonathan M Davis
wrote:
stop-the-world GC. For instance, this has come up in
discussions on games where a certain framerate needs to be
maintained. Even a 100 ms stop would be way too much for them.
In fact, it came up with the concurrent GC that was presented
at dconf 2013 that it would likely have to be guaranteed to
stop the world for less than 10 ms (or something in that range
anyway) to be acceptable for such environments. So, it _is_ a
problem for some folks.
In the renderloop you only have 15 ms, so it would be more like
2ms (not realistic). The 10 ms target is for high performance
servers and regular interactive applications.
That being said, it is _not_ a problem for most folks, and the
folks who have those sorts of performance requirements
frequently can't even use malloc after the program has gotten
past its startup phase.
I don't agree with this. You can use your own allocators that
don't syscall in critical areas.
GC-allocated or malloced. For instance, as I understand it,
Warp used the GC, but it allocated everything up front and
didn't allocate once it got going, so the GC wasn't a
performance problem for it at all, and it's _very_ fast.
A c preprocessor is a simple program that has to allocate for
macro defs, but the rest can just use static buffers... So it
should not be a problem.
Regardless, idiomatic D involves a lot more stack allocations
than you often get even in C++, so GC usage tends to be low in
Really? I use VLAs in my C++ (a C extension) and use very few
mallocs after init. In C++ even exceptions can be put outside the
heap. Just avoid STL after init and you're good.
