== Quote from nobody (n...@where.com)'s article > > 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.
I personally have not experienced this. Please be more specific: D1 or D2? If D1, Phobos or Tango? DMD, LDC, or GDC? Compiler version? Also, please file a bug report, especially if you can create a concise, reproducible test case.
