Thanks everyone, looks like i'll have to benchmark myself (which
is fine) but I'm always afraid because I know "proper
benchmarking is hard. (TM)"
Feel free to throw any other side advice in. I'm looking to get a
broad perspective on this.
Straight up shutting off the garbage collector in
Creates a Task on the GC heap that calls an alias.
If possible, there's also scopedTask, which allocates on the stack:
https://dlang.org/phobos/std_parallelism.html#.scopedTask
So my question is: Has anyone done any analysis over how "dangerous" it is to use GC'd tasks for
_small_ tasks (in
You can control when the gc runs. So if you know the allocations
are small enough that they won't OOM, then you can say
GC.disable, and it straight up won't run at all. But you can
manually run a collection cycle (during a loading screen or
whatever) with GC.collect. See
On Sat, Jan 04, 2020 at 12:51:15AM +, Chris Katko via Digitalmars-d-learn
wrote:
[...]
> I'm looking through D's parallelism module and the docs state,
> up-front:
>
> >Creates a Task on the GC heap that calls an alias.
>
> The modern, scalable way to make a parallel game engine uses
When I program, it's usually videogame ideas. That implies a
soft, real-time requirement. In general, that requires the mantra
"allocations are evil, use object pools whenever possible."
[storing data in static arrays and 'deleting' is usually just
marking an entry as is_deleted=true and
