nobody wrote: >> 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.
After enabling the gc, did you force a collection? Just enabling it won't cause one to occur. Later, Brad
