On Fri, 2011-01-07 at 01:10 +0200, David Griffiths wrote: > On Thu, 2011-01-06 at 23:27 +0100, gabor papp wrote: > > > I've added a custom allocator for all primitive data so we can intercept > > > memory calls for debugging fluxus in a slightly saner way than using > > > valgrind. > > great! i hope we can find the leak with this. > > > > i had to change malloc.h to stdlib.h in Allocator.h to make it compile > > on osx. i think this does not break anything in linux. > > Yep it's fine. I've made the stats work properly now, it keeps a set of > the pointers currently allocated. This is also all in the cpp file so we > can fiddle with the debugging without incuring a full rebuild (which > takes ages on my netbook :)
I've plotted the allocations from "plant eyes" over several hours (see attached). The primitive allocations look fine, and the graph is what I'd expect to see - it's the most complex script I have and does lots of creating and destroying of various kinds of geometry over time. Critically though, the memory use in top steadily increased from around 12% to 18% in the same period, and the game's framerate slowed too. I should graph these alongside the allocs. Two things to look at next: 1. Write a minimal version of the pdata-map! script in c that we can test in the same way. This could eliminate fluxus, and give us something to send to the racket list that they can easily test (they normally respond quickly if you give them a nice example they can compile in c). 2. Plot the distribution of allocations to see if we are generating lots of small "holes" in memory that prevent allocations of larger regions - memory fragmentation. This is less likely I think - but could explain the framerate reduction, as malloc will be taking longer to find free spaces. cheers, dave
<<attachment: allocplot.png>>
