Fix memory leak in pdfjs.js. #42
Conversation
A large amount of data is pushed into the global variable 'canvas_logs' which
isn't cleared in runPdfJS. On each iteration the list grows, eventually
significantly so.
On a Linux machine with a recent-ish V8, it manages 2777 iterations before an
allocation fails (at which point it's allocated over 2GiB of virtual memory, and
used about 1.4Gib) and V8 crashes ("Fatal error in CALL_AND_RETRY_LAST"). From
iteration ~800 onwards, things start slowing down gradually; at iteration ~1700,
they start slowing down considerably; and at iteration ~2750, performance falls
off a cliff; presumably as the GC comes under more and more strain.
By emptying canvas_logs at the end of each benchmark run, we make the
benchmark's performance more consistent. With this patch I can happily run this
benchmark in constant memory for 10000 iterations, with no discernible change in
iteration time over that.
|
@ltratt I'm afraid emptying |
|
@woess Hello Andreas, yes, I think you're right. That said, IMHO, the current placement of the correctness checks means that one is forced to choose between a) predictable performance on each iteration b) correctness checks. Both options suck, though I think for a benchmark the former sucks marginally less. It would be nice to do both though! I've had a quick look, and the code is doing something that I don't understand. If I try and move the correctness check into |
|
@ltratt Agreed. You could clear the I don't see the |
This means that the checks in tearDownPdfJs are still executed.
|
OK, so I meant to look at this and then... forgot. I've made the change that Andreas (@woess) suggested. I believe that it does the right thing: the benchmark no longer leaks memory; but the checks are still run. I'd suggest I squash this before any possible merge, assuming people agree that this is the right fix. |
|
I think it's officially time to "ping" this one. Or we can let it die -- but, if I'm honest, I'd prefer someone to state explicitly that it won't be merged. |
|
It won't be merged. Octane is retired and no longer maintained. Sorry for the long communication cycle. |
A large amount of data is pushed into the global variable
canvas_logswhich isn't cleared in runPdfJS. On each iteration the list grows, eventually significantly so.On a Linux machine with a recent-ish V8, it manages 2777 iterations before an allocation fails (at which point it's allocated over 2GiB of virtual memory, and used about 1.4Gib) and V8 crashes (
Fatal error in CALL_AND_RETRY_LAST). From iteration ~800 onwards, things start slowing down gradually; at iteration ~1700, they start slowing down considerably; and at iteration ~2750, performance falls off a cliff; presumably as the GC comes under more and more strain. Here's a graph showing this (x axis=iteration number; y axis=time):It can be a little hard to see what's going on because the last iteration or two are so slow and, in a sense, distort the rest of the graph. If I chop off the last 80 iterations, one can still see that odd things are happening:
By emptying
canvas_logsat the end of each benchmark run, we make thebenchmark's performance more consistent. With this patch I can happily run this
benchmark in constant memory for 10000 iterations, with no discernible change in
iteration time over that.