PDF XChange Forum

Hi all & Tracker team,

I just wanted to quickly report that PDF-XChange Editor can be cranked up to use use dozens of gigabytes of RAM without any problems.

Below is a screenshot from Task Manager showing PDF-XChange Editor using almost 22 GB of RAM (on a 32 GB system):



This is a thousand pages PDF file displayed on a 4K screen, after all pages, all thumbnails and all text have been loaded into RAM.

It's incredible how fast you can scroll, navigate and search the PDF in this state where everything is cached in RAM!

Particularly scrolling through a PDF file shown in full-page view on a retina hidpi screen with like 20 fps (or, pages per second :) is an amazing experience.

It makes me very happy every day that the feature to keep everything in RAM as long as possible (i.e. until the file is closed) has been implemented about a year ago!



Of course it would still be better (and the respective feature is highly anticipated) if a few pages in both directions would be pre-rendered, as discussed above.

Keep up the great work
Best regards
David


Edit:
Whoaa, a while later memory usage is down to under 6GB of RAM while there is no perceivable speed drop when navigating the PDF!



How is this possible? Is this Windows swapping out stuff from RAM to the hard drive -- but without much speed loss?
(in my case it's a SSD)

Are you sure that you didn't just check a few dozen pages around the last position when you noticed the memory usage drop? Did you check both ends of the document and in between to make sure that all pages are still cached?

Yep Timur. I checked (scrolled through) the entire document as well as through all thumbnails and all of the text again, and memory usage still stayed low in the 6GB range. For me the only explanation for this is some clever Windows swapping together with a fast SSD.

Or the ingenious Tracker Devs have integrated some RAM memory compression scheme…

Or it used up more memory than what was needed to cache the document and then at some point cleaned up its own mess.

Haha, you could be right, since a quick calculation for the document (actually having 930 not 1000 pages) yields about 7,6 GB uncompressed data (930 Pages at 1428 x 2020 pixels at 24 bit color depth; plus 930 thumbnails with 191 x 270 pixels plus around 2MB of uncompressed text)

So, well done Tracker Team for silently cleaning up those 20 Gigabytes of 'memory mess' in the background!

Maybe it would even be possible to compress at least the image data in RAM using RLE or some fast algorithm, which should bring those 1000 pages @ 4K resolution down from 7,5 GB to around 1,1 GB according to a quick'n'dirty estimation