Hi all, I had a look at the issue and could finally pin it (more or less).
Codespeed does destroy and recreate the whole element containing the canvas, so it is NOT a but in jqPlot (nor in Codespeed). It is a tricky GC issue where memory taken by big canvases is not properly freed. It probably affects several bowsers with modern JS JITs. Actually, in Firefox 3.6 it is so bad that not even closing the tab frees up the memory for a while! Chrome exhibits similar behaviour, but it does free old canvases after 20-40s. I am sure you will be interested in the fact that Konqueror 4.4 (with KHTML and kjs), which probably doesn't have such an aggressive JIT (or no JIT at all?), does NOT suffer this problem. Every refresh properly frees up the memory of the old canvas. For anyone further interested, Dmtrii did an excellent job filling a new bug for it with simple example code that triggers the problem (I added my observations there): https://bugzilla.mozilla.org/show_bug.cgi?id=621416 So what about speed.pypy.org? It being a multi-browser GC bug, I did the only thing I could do: limit the size of the sometimes ridiculously big horizontal plots ;-) It now has a 2000px limit. It does not completely fix the issue, but it is much more bearable. In the first 2 refreshes (selecting or -deselecting benchmarks), FF even manages to free up the memory. After that it keeps on eating more, but its much better. Thanks Dmitrii for caring! :-D (Please tell me whether it got better for you.) Cheers, Miquel 2010/12/23 Armin Rigo <[email protected]>: > Hi Paolo, > > On Thu, Dec 23, 2010 at 3:09 PM, Paolo Giarrusso <[email protected]> > wrote: >> From your description, I guess that what you describe as "raw memory" >> is not accounted in the stats triggering GC. That would explain the >> behavior you describe, and suggest an easy fix. Indeed, one could wrap >> the raw-memory allocator to create and update such stats; then the >> heap-overflow check could consider them to decide whether to trigger >> GC. The details of the modified heap-overflow check would probably not >> be entirely trivial, but still doable. > > Absolutely. I will write it down in extradoc/planning/ for now. > > > Armin > _______________________________________________ > [email protected] > http://codespeak.net/mailman/listinfo/pypy-dev > _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
