> One thing you could try is disabling the GC (this really just disables > automatic > running of the collector) and run it manually at points that you know make > sense. > For example, you could just insert a GC.collect() statement at the end of > every > run of your main loop. > Another thing to try is avoiding appending to arrays. If you know the length > in > advance, you can get pretty good speedups by pre-allocating the array instead > of > appending using the ~= operator. > You can safely delete specific objects manually even when the GC is enabled. > For > very large objects with trivial lifetimes, this is probably worth doing. > First of > all, the GC will run less frequently. Secondly, D's GC is partially > conservative, > meaning that occasionally memory will not be freed when it should be. The > probability of this happening is proportional to the size of the memory block.
I have tried all these: with GC enabled only periodically runs in the main loop, however the memory still grows faster than I expected when I feed more data into the program. Then I manually delete some specific objects. However the program start to fail randomly. Has anyone experienced similar issues: i.e. with GC on, you defined you own dtor for certain class, and called delete manually on certain objects. The program fails at random stages, with some stack trace showing some GC calls like: 0x0821977a in _D2gc3gcx3Gcx16fullcollectshellMFZk () I suspected the GC is buggy when mixed with manual deletes.
