[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