[Scummvm-devel] Memory consumption in GUI branch

Vicent Marti tanoku at gmail.com
Sun Oct 5 13:56:24 CEST 2008


Hello Max, everyone:

I've also ran my own memory benchmarks; overall, I'd say that the
memory consumption on the new GUI is very acceptable, specially when
comparing the new features vs the old branch.
You are right on those two enormous memory buffers. They are also on
the trunk GUI (although they are not called the same) because of a
limitation on the SDL/generic backend system. We need to cache the
whole overlay in memory and then blit parts of it through the OSystem
call because OSystem doesn't offer support for *actually* drawing on
the overlay. Maybe this is something that could be worked on.

I've implemented a fixed memory pool on the XML parser this morning,
together with a new svnmerge and a round of fixes (jeez, looks like
everyone loves to break my branch). The speed increase on my computer
is only marginal, but I'm guessing it'll be much more significant on
other platforms where memory allocation is a problem.

I'll keep looking for more places I can cut down to save more memory
-- it would be awesome if the new GUI used less memory than the old
one. Meanwhile, I can't wait for that merge to happen. :)

Cheers,


Vicent Martí
----------------
http://www.smartlikearoboc.com



On Fri, Oct 3, 2008 at 6:45 PM, Max Horn <max at quendi.de> wrote:
> Hi all, hi Vicent,
>
>
> I used a nice Apple tool (Instruments.app) to study a bit where we use
> what kind of memory in ScummVM. In particular, with the GUI branch,
> and using
>   -eadlib -g1x
> as well as the classic built-in theme, figuring that this should be
> the setup using least memory and being common to portable devices.
> What I noticed:
>
> * The SDL backend uses the biggest chunk of memory, for graphics
> buffers. Custom backends will differ, so I am not caring about that
> for now.
>
> * A lot of memory is allocated by the OS itself, for audio resampling,
> graphics, etc. -- this is of course OS X specific, so I won't bore you
> with it.
>
> * We allocate two 256K buffers in InitLUT -- that's used by HQ2x/HQ3x,
> so I hope it won't affect low-end ports.
>
> * Apparently, ThemeEngine::screenInit allocates two 155648 bytes
> buffers (for Graphics::Surface). Note: OS X rounds memory block sizes
> a bit, but I guess those buffers are 320x200x2 big. That's 300KB in
> total. I wonder if we really need both of these?
>
> * XMLParser::parse() invokes new about 560 times, to allocate
> ParserNodes (each taking up a 1024 bytes block over here) -- that's
> far from the couple millions we used to have, but still not quite
> optimal. I think those are only kept around temporarily, so I am not
> concerned about memory use, only about the number of allocs (which
> might grow for bigger / more complex XML files, right?). So, it might
> help to keep a (Fixed)MemoryPool for the ParserNodes, to reduce the
> number of allocs. Would be easy enough to implement that.
>
> * A big chunk of memory is used to represent my huge config file
> within the ConfigManager. A lot more than what the file size of the
> config file would suggest. So, I guess working on that would help to
> get down memory usage, at least for "power users". This holds for
> trunk, too, and is independent of your GUI work, of course.
>
>
>
> All in all, the GUI branch seems to be quite good when it comes to
> memory consumption, with the possible exception of those two memory
> buffers -- but I think those are in trunk, too, so it's no regression.
>
> Over all, I think we could merge this
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
>




More information about the Scummvm-devel mailing list