[Scummvm-devel] memory footprint issues

Marcus Comstedt marcus at mc.pp.se
Thu Mar 6 15:47:09 CET 2003

Ok, here are the preliminary results of my memory profiling.

These are the 10 individual functions that had the largest memory
footprint (maximum number of allocated bytes at any one time during
the program execution) during my test run:

 9000000  Sound::playBundleSound(char*)
 6150000  SoundMixer::ChannelStream::ChannelStream[in-charge](SoundMixer*, void*, unsigned long, unsigned, unsigned char, long, long)
 814162   Scumm::createResource(int, int, unsigned long)
 662230   operator new[](unsigned)
 595350   Sound::playBundleMusic(char*)
 308872   Sound::decode12BitsSample(unsigned char*, unsigned char**, unsigned long, bool)
 140340   Scumm_v6::o6_kernelSetFunctions()
 108187   Sound::playBundleSound(char*)
 98136    Bundle::openVoiceFile(char const*, char const*)
 88868    OSystem_Dreamcast::create()

The value for Scumm::createResource (814k) matches the debug outputs
from expireResources() and isn't dangerously high.  (In fact, I think
_maxHeapThreshold should probably be _raised_ to 1M or something like
that, right now a lot of time is spent running expireResources (it's
called several times a second) without achieving anything (the
_allocatedSize won't go down below 800k anyway since the resources are
in use).

The "operator new[]" entry could of course be subdivided into the
functions that actually invoke the new[] operator, but for 600k I
don't know if it's worth the effort, it's probably ok anyway.  I
suspect most of it is various screen buffers.

However, the top two entries are definitely not ok.

playBundleSound has allocated (and not freed) _NINE MEGS_ all for
itself.  This is of course totally ridiculous considering the entire
game is supposed to run in eight.  Memory leak?

The SoundMixer also seems to have wandered off into a world of its own
with an accumulated set of allocations amounting to over 6 megs.  Leak
here too?

If these two hogs are fixed, I think memory usage should drop to
reasonable levels throughout the game.

(I also did a small test running scummvm under Linux/PPC with a `top'
 in the background.  Right at the start of the game (just after the
 opening movie), the process size was 4 meg.  By the time I had
 detonated the nukes and went down into the tunnel, it had increased
 to 18 megs.  Saving the game, restarting scummvm, and loading the
 savegame brought down the process size to 4 megs again.  So there
 definitely seems to be some kind of leak.  I don't know if the sound
 code is directly or indirectly responsible though.)

  // Marcus

More information about the Scummvm-devel mailing list