There are legitimate uses cases when you can't afford the runtime machinery (attach/detach every incoming thread in a shared library), more than not being able to afford the GC from a performance point of view.

GC gives you higher productivity and better performance with the time gained.

Now, @nogc code is good for performance since (even in a GC program) you will have no hidden allocation anymore, if you also disable postBlut and copy ctor, unlike in C++ where hidden copies are rempant.

On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:

I don't use it always, but wish I could do it.
Meanwhile, I make plenty of nothrow @nogc code.

On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:

Yes I am, but my needs are very specific and only the "betterC" subset fits it, and it's certainly not the nominal case in D, nor should it be. Some of the D target have strict requirements, for example Hipreme engine use audio-formats (nothrow @nogc), but audio-formats uses exceptions internally, maybe that will be an issue, depending on the flavour of D runtime it uses.

On Sunday, 4 December 2022 at 09:53:41 UTC, vushu wrote:

If your program runs, does some stuff, and terminates, use the GC.
If your program runs, stays up for a while with user occasionally interacting with it, use the GC.
If your program runs, and stays up 24/7 doing things in the background, use the GC.

If your program is a game meant to run at 60+fps, and any sudden skip or interrupt is unacceptable, no matter how minor (which it should be), plan carefully about how to manage your game objects, because naive GC instantiation and discarding isn't going to cut it. malloc/free, pre-allocated lists, and other strategies come into play here. In a desperate pinch you can also manually GC.free your GC-allocated objects but this is not recommended. The GC can still be used for allocations that are not likely to significantly affect performance every frame (strings, occasional user-generated information requests, first-load data instantiation, Steam avatars, etc) -- but also be even more careful when you start mixing and matching.

I find that @nogc is a bit of a false idol though, even in situations where the GC is deliberately being avoided. It simply adds too much pain to trying to make everything compliant, and certain things just plain don't work (amazingly, the non-allocating form of toString can't be @nogc), so I simply avoid it and "be careful" (and/or hook into the GC so I can monitor if an unexpected allocation happens). If you're writing code that's going to run on a space shuttle or life support system, then yeah you might consider the extra effort, but in my use cases it simply fails the cost-benefit analysis.

For any strategy, it's still a good idea to have a good understanding of or profile your allocations/deallocations so you're not just spending memory haphazardly or generating excessive collections.

On Monday, 5 December 2022 at 10:48:59 UTC, Guillaume Piolat wrote:

Thanks for the description of your usecase, good to know your perspective when considering using a library :)

On Sunday, 4 December 2022 at 17:47:38 UTC, ryuukk_ wrote:

I agree with you i depends on the usecase, I will consider that thanks.

On Monday, 5 December 2022 at 14:48:33 UTC, cc wrote:

Thanks a lot for your advice :)