Memory consumption - Special Use case

[DavidVentura]

I made the following example: http://jsfiddle.net/zkq19spu/2/
This represents my use case: Drawing a page of a PDF to a canvas, doing something to the canvas, then saving the image, drawing the next page to the canvas [..]

This seems to be an edge case, because the memory usage shoots to over 900MB with a 22MB pdf.
Could you help me to modify the source to:
*Disable the cache or shrink it to the minimum size
*Delete the canvas on render finish

With my use case I don't need to go back to the previous pages, and after the rendering is finished I don't need it anymore.

[timvandermeij]

I think you forgot to call destroy(), which should free the page's memory.

[DavidVentura]

calling page.destroy just before

                render(pageNum+1);  

Doesn't help much.
IE: calling page.destroy() at the end of page.render(...).then() doesn't help

[yurydelendik]

Is there something special about your 22MB pdf? Such as lots of hi-res images, huge pages, lots of fonts, etc. page.destroy() will remove image resource, however it will not cleanup the fonts. Can you analyze memory snapshots to tell what's holding the memory?

[yurydelendik]

Just to note "cosa"/reader.readAsDataURL(file); consumes at least 30MB (base64 on main thread) + 30MB (base64 in the worker) + 22MB as Uint8Array(in the worker) at some point. Could you readAsArrayBuffer and init the getDocument with Uint8Array and not use data URL?

[DavidVentura]

That example was old; I'm using URL.createObjectURL(file) now, do you consider readAsArrayBuffer better than createObjectURL?

http://jsfiddle.net/zkq19spu/4/

Using readAsArrayBuffer my ram usage (OS) goes 970 ->1387 (when running the demo) with a 802KB, 45 pages long PDF file, which is mostly text over a background.

I know this is an edge case (iterating over the entire PDF file as fast as possible)

[yurydelendik]

Tried a 23M document and your jsfiddle, ff nightly did not consume more than 650MB (And I suspect 100MB of that just duplicate of the initial pdf data in base64 or binary form, some of that Firefox itself, rest of that font and other caches):

Can you also specify your configuration: browser, os and their versions?

[yurydelendik]

Using URL.createObjectURL(file) is better if it works for you.

Please provide URL to your PDF document

[DavidVentura]

Ok this is a 22MB, 112Page pdf (somewhat nsfw) that was given to me by a doctor.
http://davidventura.com.ar/LOS%205%20ELEMENTOS%2007.%20BsAs.ppt11.pdf

This is an 802KB, 47 page pdf (totally sfw)
http://davidventura.com.ar/PrimeraClase.pdf

I'm looking to get this working on mobile, so '650MB' of ram is a pretty big deal. I don't know if there's an easy way to discard 'old' (as in not-currently-active) pages/canvases.

[DavidVentura]

I tried to destroy all previous pages on WorkerTransport_getPage, but it seems like they get marked as "pendingDestroy" but do not get destroyed shortly (should it be immediately?)

Around line 2690
below

      var pageIndex = pageNumber - 1;

add

var dest;
        for(var i=0;i<pageIndex;i++) {
            dest = this.pageCache[i];
            if (dest){
                console.log("Destroy: " + i);
                dest.destroy();
            }
        }

Every time this runs I get every slide logged:
[0], [0,1], [0,1,2]...[0,1,2,...numPages-1]
which means that they are not being destroyed

Also, I tried adding a 1 second delay between page renders, it helped a little bit (peak consumption went from 300MB to 250MB)

[DavidVentura]

It seems like all the images are being kept in memory.. I saved a memory report before and after iterating very quickly through the pdf.
Here's a screenshot of the diff.. note that this is 230mb of images for a ~800kb pdf

[fbender]

Is this still an issue with the latest version? @DavidVentura

[timvandermeij]

No response, closing for now.