Disable GC entirely

[Jacob Carlborg]

On 2013-04-08 05:12, Manu wrote:

> Bear in mind, most remaining C/C++ programmers are realtime programmers,
> and that 2ms is 12.5% of the ENTIRE AMOUNT OF TIME that you have to run
> realtime software.
> If I chose not to care about 2ms only 8 times, I'll have no time left. I
> would cut off my left nut for 2ms most working days!
> I typically measure execution times in 10s of microseconds, if something
> measures in milliseconds it's a catastrophe that needs to be urgently
> addressed... and you're correct, as a C/C++ programmer, I DO design with
> consideration for sub-ms execution times before I write a single line of
> code.
> Consequently, I have seen the GC burn well into the ms on occasion, and
> as such, it is completely unacceptable in realtime software.
>
> The GC really needs to be addressed in terms of performance; it can't
> stop the world for milliseconds at a time. I'd be happy to give it
> ~150us every 16ms, but NOT 2ms every 200ms.
> Alternatively, some urgency needs to be invested in tools to help
> programmers track accidental GC allocations.

An easy workaround is to remove the GC and when you use the GC you'll 
get linker errors. Not pretty but it could work.

> I cope with D in realtime software by carefully avoiding excess GC
> usage, which, sadly, means basically avoiding the standard library at
> all costs. People use concatenations all through the std lib, in the
> strangest places, I just can't trust it at all anymore.
> I found a weird one just a couple of days ago in the function
> toUpperInPlace() (!! it allocates !!), but only when it encountered a
> utf8 sequence, which means I didn't even notice while working in my
> language! >_<
> Imagine it, I would have gotten a bug like "game runs slow in russian",
> and I would have been SOOOO "what the ****!?", while crunching to ship
> the product...

To address this particular case, without having looked at the code, you 
do know that it's possible that the length of a Unicode string changes 
when converting between upper and lower case for some languages. With 
that in mind, it might not be a good idea to have an in place version of 
toUpper/Lower at all.

> d) alternatives need to be available for the functions that allocate by
> nature, or an option for user-supplied allocators, like STL, so one can
> allocate from a pool instead.

Have you seen this, links at the bottom:

http://3d.benjamin-thaut.de/?p=20

-- 
/Jacob Carlborg