Memory + Disk cache issues

Forum for the PDF-XChange Editor - Free and Licensed Versions

Moderators: TrackerSupp-Daniel, Tracker Support, Vasyl-Tracker Dev Team, Sean - Tracker, Paul - Tracker Supp, Chris - Tracker Supp, Tracker Supp-Stefan, Ivan - Tracker Software

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 11:36 am

I put this in its own thread, because it's more of a bug-report than a discussion:

1. Disc cache

It seems that Editor makes no use of its disc cache whatsoever! While it keeps writing to its cache directory (temp\PDFXedit) there are no read operations happening. One could suspect that all disc cache data is still present in Windows ram-cache, but because of bug no. 2 (below) I am quite sure that this is not the case.

Editor simply does not seem to use the disc cache once decoded image information is flushed from its own memory cache (due to size constraints or bug no. 2 below). I monitored disk operations and mostly only see write operations happening, hardly any read operations ever, instead pages are decoded from scratch again.

Unfortunately Editor also flushes/deletes its disc cache when the program is closed. So even if it was working properly, it would only help for a single session.

2. Memory cache

This one irks me even more. Editor keeps flushing its memory cache for no apparent reasons, usually down to a total commit size of only around 640-650 mb. It happens when the whole document is inside the cache, it happens when only parts are in cache, it happens when flipping pages and it happens when leaving Editor idle. It happens at 1.6 gb, 2.5 gb, 3.5 gb or 4 gb, so there doesn't seem to be any threshold point. It happens regardless of what memory cache size is set up, I tried 12 gb peak cache with free RAM being at least 13 gb, but to no avail.

Obviously this slows down my work considerably, especially since I work with files that easily use over 3 gb cache per single file (if loaded completely).
Last edited by Timur Born on Fri Jul 28, 2017 12:32 pm, edited 1 time in total.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 12:31 pm

For better understanding: What information is held in the memory cache, decoded images only or also pre-rendered parts (blocks) of pages?

Lzcat - Tracker Supp
Site Admin
Posts: 712
Joined: Thu Jun 28, 2007 8:42 am

Re: Memory + Disk cache issues

Post by Lzcat - Tracker Supp » Fri Jul 28, 2017 1:16 pm

Hi Timur.
It seems that Editor makes no use of its disc cache whatsoever! While it keeps writing to its cache directory (temp\PDFXedit) there are no read operations happening. One could suspect that all disc cache data is still present in Windows ram-cache, but because of bug no. 2 (below) I am quite sure that this is not the case.

Editor simply does not seem to use the disc cache once decoded image information is flushed from its own memory cache (due to size constraints or bug no. 2 below). I monitored disk operations and mostly only see write operations happening, hardly any read operations ever, instead pages are decoded from scratch again
And how you determine was disc cache used or not? By monitoring using some external program or by disk activity? Editor use disc cache as second level cache - first is in memory. So to see reading from disc cache you should make sure that image was freed from memory (but if you have a lot of RAM this is not simple). Typically you should use more than 2Gb of memory for images cache (so some images will be released from memory) and then return to images which was used first. And this is not guarantee that data will be not loaded from windows cache. Main reason to implement disc cache is use in 32-bit code and on PC with small amount of RAM (or cases when editor cannot use a lot of RAM). Simply saying - to see effect of disc cache you should have much less of physical RAM (1Gb for example, in total).
Unfortunately Editor also flushes/deletes its disc cache when the program is closed. So even if it was working properly, it would only help for a single session
Yes, this is by design. Moreover, disc cache is limited in size, and this limit is 16 Gb for all opened documents. We do not waste disk space to low possibility that you will open document in some future.
Editor keeps flushing its memory cache for no apparent reasons, usually down to a total commit size of only around 640-650 mb. It happens when the whole document is inside the cache, it happens when only parts are in cache, it happens when flipping pages and it happens when leaving Editor idle. It happens at 1.6 gb, 2.5 gb, 3.5 gb or 4 gb, so there doesn't seem to be any threshold point. It happens regardless of what memory cache size is set up, I tried 12 gb peak cache with free RAM being at least 13 gb, but to no avail.
Sorry, but I cannot reproduce such behavior. Which settings are you using? Which OS and hardware?
Editor can clear it memory cache in 3 situations:
1. Total memory (or address space) limit exceeded. Oldest items will be removed from cache until memory usage will fit limits.
2. Document is closed. All data related to that document is removed from memory.
3. If you are not using some data more than specified period of time it will be removed from cache. For now this limit is hardcoded to 10 minutes, which is enough for most cases of PDF reading. This is done to prevent Editor "eating" a lot of memory even you are not using it for a while.
Obviously this slows down my work considerably, especially since I work with files that easily use over 3 gb cache per single file (if loaded completely).
Looks like you have some very specific scenario of Editor usage, because I cannot reproduce your behavior here ...
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 4:12 pm

First of all: Thanks for the quick reply and for looking into this! :)
Lzcat - Tracker Supp wrote:And how you determine was disc cache used or not? By monitoring using some external program or by disk activity?
Yes, like I wrote I monitored disk activity (via Windows Resource Monitor). Editor's disk cache (temp/PDFXeditor) write activity happens under the "System" process, so I monitored both Editor's and the System process' activity. If you need me to use specific software to monitor this, just let me know and I will install that for monitoring.
Editor use disc cache as second level cache - first is in memory. So to see reading from disc cache you should make sure that image was freed from memory (but if you have a lot of RAM this is not simple).
When Editor flushes its memory cache either due to size constraints (I tried the minimum size of 100 mb to quickly fill the cache) or due to the mentioned bug there is no read activity happening from Editor's disk cache, none whatsoever. Even more important, performance is very clearly dropping to the same level of previously undecoded pages.

After comparing the size of the disk cache with the amount of decoded data in the memory cache it becomes clear why no disk cache read usage is happening: While over 2.5 GB data reside in Editor's memory cache there is less than 100 MB of data (often less than 60 MB) in temp\PDFXeditor. So unless there is some other folder anywhere (to which I monitor no write operations) I suspect that the necessary cache data never reached the disk to begin with, so there is nothing to read available.
Typically you should use more than 2Gb of memory for images cache (so some images will be released from memory) and then return to images which was used first. And this is not guarantee that data will be not loaded from windows cache. Main reason to implement disc cache is use in 32-bit code and on PC with small amount of RAM (or cases when editor cannot use a lot of RAM). Simply saying - to see effect of disc cache you should have much less of physical RAM (1Gb for example, in total).
I specifically set Editor to use a small cache to test this and can reproduce the lack of disk reading. Furthermore, Editor's memory cache flush behavior makes using a disk cache useful, but even after the cache is flushed no read operations are happening.
Yes, this is by design. Moreover, disc cache is limited in size, and this limit is 16 Gb for all opened documents. We do not waste disk space to low possibility that you will open document in some future.
Give us an option for this please, including the ability to set the maximum amount of disk space used. I paid lots of money for my hardware and have plenty of disk/SSD space free, which I want to be used when available. Time is more valuable to me than unused disk space and I keep opening the same documents over and over again.
Sorry, but I cannot reproduce such behavior. Which settings are you using? Which OS and hardware?
- Like I wrote before it happens at various different settings for disk cache. "Auto" uses 25% as it seems. I tried up to 75% (12 GB).
- Windows 10 Creators.
- AMD Ryzen 1800X (8 cores / 16 threads), 16 GB RAM, 1TB SSD.
Editor can clear it memory cache in 3 situations:
1. Total memory (or address space) limit exceeded. Oldest items will be removed from cache until memory usage will fit limits.
This makes sense, but is not the case here.
2. Document is closed. All data related to that document is removed from memory.
Makes sense again, albeit one could argue that at least its disk cache data should be retained in case that it's reopened again.
3. If you are not using some data more than specified period of time it will be removed from cache. For now this limit is hardcoded to 10 minutes, which is enough for most cases of PDF reading. This is done to prevent Editor "eating" a lot of memory even you are not using it for a while.
This likely is the source of the bug: I took another look and found out that Editor flushes its memory cache down to about 640 MB total commit size every minute! So only the very last few pages are retained. It's important to note that this is quite a complete flush, not just flushing pages that have not been accessed for one minute.

And if you allow a user to set the peak size of the memory cache via preferences then don't hardcode the flush timer, please. The choice to forfeit memory in return for faster decoding times was already made by the user. At least add an option to change this timer. You could maybe turn the cache from private memory to working set, so that Windows releases it when absolutely necessary. But as long as most of my memory is free I want it used as image cache up to the limit I set in preferences before.
Looks like you have some very specific scenario of Editor usage, because I cannot reproduce your behavior here ...
I am using very image heavy documents, sometimes spanning hundreds of pages with hundreds of images. And I am sometimes viewing images on a 2560 x 1600 30" display, which means that pages/images are decoded to large sizes. This is where the image cache is needed the most, especially since Editor still does not pre-render. I assume this would be even worse on 4-8K displays.

User avatar
David.P
User
Posts: 852
Joined: Thu Feb 28, 2008 8:16 pm
Location: Germany

Re: Memory + Disk cache issues

Post by David.P » Fri Jul 28, 2017 5:37 pm

Hi @all,

I can confirm that PDF-XChange Editor flushes its memory cache regularly.

Once you have your entire PDF beautifully loaded in RAM cache (i.e. all thumbnails, all pages and all text), PDF-XChange Editor simply FLIES, and everything happens instantaneously.

But then, after some time (in my case it is longer than a minute, I guess it's more like 15 minutes here) all the gigabytes of beautifully rendered cache content:
Image
(RAM and CPU usage for rendering a large document)

...are discarded and flushed -- only having to be re-created from scratch the next minute, when using the respective function again (i.e. flipping pages, browsing thumbnails or searching for text).

Then, before and while re-creating the cache content, text search in a PDF is MUCH slower (about 10-20 times slower), browsing through thumbnails is much slower, and page flipping CAN be much slower (depending on page content).

Therefore, I strongly support the request that cache handling should be made user-adjustable – or at least the cache of any open document should not be flushed until the document is closed.

Additionally, as discussed here, it would be great if PDF-XChange Editor could be set such that some background thread crawls the entire document as soon as it is opened, creating and caching the entire document in memory (i.e. pages, thumbnails and text).

Thanks very much to the Devs for considering,

Keep up the great work
Cheers
David
David.P
PDF-XChange Pro

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 8:16 pm

Seems that I was wrong concerning the regularity of the flushes. Here is a screenshot where it happens anywhere between 2 minutes and 30 seconds. This time I used two documents and it seems that partial flushes happen where the data of one document is flushed.

Anyway, none of these should happen at all, especially not in such short time-spans. Editor was set to 8 GB peak cache size, cache content never reached more than 6 GB in the screenshot.
Editor_ram_cache_bug.jpg
Here is an example that where the content of a single document was flushed after exactly one minute.
Editor_ram_cache_bug2.jpg

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 8:28 pm

Same document, 2 minutes later (closed the second unused background tab before building up the cache). See how in the middle of building up the cache (flipping pages via holding cursor key) the cache is flushed to zilch.
Editor_ram_cache_bug3.jpg

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Jul 28, 2017 8:35 pm

Also take note how in the first screenshot the disk I/O is practically zero (0!) all the time, same as in David's screenshot!

Given how little data is written and how infrequently it happens I don't think the data written by the SYSTEM process to temp\PDFXeditor is even cache data. I would also expect the Editor process to handle writing and reading of cache data on its own? Anyway, disk caching is not happening here.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 02, 2017 6:46 am

Is this still looked into?

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 02, 2017 12:50 pm

Hi Timur,

I'll bring this up for discussion in our meeting tonight. Unfortunately there's little more that myself or my Support colleagues can offer on this, as it requires an intimate knowledge of our low-level application functionality that we just don't have.

Thanks for your patience, as always!
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Aug 04, 2017 8:13 am

Any results from the discussion? Are the problems I reported handled as bugs?

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Fri Aug 04, 2017 8:19 am

Hi Timur,

I'm still waiting for the devs. to take a look at this. The developers that need to weigh in are our lead developers, so unfortunately they're taken up with high priority issues and requests for the time being. If nothing has been said by Monday, I'll chase this up and will see if we can get some movement.

Thanks,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 09, 2017 8:02 am

I know your developers are busy writing version 7 and stuff, but I would like to know if this is acknowledged as a bug? I demonstrated that memory cache is flushed as early as 30 seconds after build-up and that no disk I/O for disk cache is happening. This seems like a pretty considerable performance issue.

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 09, 2017 8:11 am

Hi Timur,

Thanks for the push - Yesterday was a little hectic as one of us on the European shift is off for the next two weeks, so this slipped my mind. Apologies for that!

I've forwarded this along again. Hopefully the devs. will be able to look at this now that the new build is out.

As always, thanks for being so patient!
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 09, 2017 8:30 am

The latest build 322.6 is listed as 322.5 on the website and Editor's updater doesn't find it (at least not my Pro version). ;)

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 09, 2017 8:50 am

Hi Timur,

The new build was release quite late last night, Canadian time, so the Version History and Website records will be updated later today. As for the Updater, this needs to be updated by the devs. in the Ukranian office. I actually contacted them a few minutes before seeing this post about exactly that, so hopefully that will be up soon.

Cheers,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 09, 2017 10:01 am

The new build is now available via the Updater :)
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 16, 2017 1:33 pm

One week later I still wonder if this got a bug ticket?

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 16, 2017 1:47 pm

Hi Timur,

There's no ticket yet - I'm still waiting for the devs. to look into this. I'll give them a push again.
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 16, 2017 1:59 pm

I checked the latest version and saw the RAM cache still flushed after 30 seconds and then again after 60 seconds.

User avatar
David.P
User
Posts: 852
Joined: Thu Feb 28, 2008 8:16 pm
Location: Germany

Re: Memory + Disk cache issues

Post by David.P » Wed Aug 16, 2017 2:27 pm

Hi @all,

In supporting this request, I would like to add that today I am working with a typical ~1000-page PDF again. Searching this PDF takes about 30 seconds in PDF-XChange Editor -- initially, or after the text cache has been flushed (which seems to happen about every 10-15 minutes). Searches with text cache active however take less than 1 second (i.e. are instantaneous), so it can be said that keeping the text cache in memory can speed up document search by a factor of about 100.

And this makes an enormous difference, even more when we consider that of course Ad*be Acr*bat does NOT cache the text at ALL (neither the thumbnails btw.) and therefore takes crazy ~30 seconds for EVERY search – unusable.

Thus, while I can almost live with the current cache handling (being already lightyears ahead of Acr*bat) I still very much support the request for further improvements, like for example making cache-flushing user-adjustable.

Keep up the great work
Regards
David.P
David.P
PDF-XChange Pro

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Wed Aug 16, 2017 2:38 pm

Hi David,

The search cache is separate from the rendering cache and that 10min -15min flush is, to the best of my knowledge, by design. We may be able to increase it at little, but typically 10-15mins is enough for search docs.
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

User avatar
David.P
User
Posts: 852
Joined: Thu Feb 28, 2008 8:16 pm
Location: Germany

Re: Memory + Disk cache issues

Post by David.P » Wed Aug 16, 2017 2:56 pm

Hi Will,

thanks for your reply. Yes, text cache flushing seems to be by design (i.e. not a bug) – however making it (for example) adjustable would be still a good thing™ IMHO :)

Cheers
David
David.P
PDF-XChange Pro

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 16, 2017 3:54 pm

I am using single documents for hours on end, needing search over and over again. Sometimes I leave them open while leaving the computer (with or without standby) and then come back to read on. So having the search cache not being flushed without need would very much be appreciated.

My computer hardware was a lot more expensive than both X-Change Pro and the PDF files I bought. Please make use of that hardware instead of flushing it back to being unused every few seconds to minutes. Thanks in advance!

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 16, 2017 7:14 pm

And of course the RAM cache still should not flush every 30-60 seconds at all. This clearly is a bug.

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Tue Aug 22, 2017 9:31 am

Hi guys,

Unfortunately the developers that need to look into this are on holiday for the next two weeks. I'll do my best to get some movement on this topic as soon as they're back.

Sincere apologies for the delay!
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Tue Aug 22, 2017 10:24 am

I already thought so. No problem.

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Tue Aug 22, 2017 10:36 am

Thanks for being so patient!
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

User avatar
Will - Tracker Supp
Site Admin
Posts: 6806
Joined: Mon Oct 15, 2012 9:21 pm
Location: London, UK
Contact:

Re: Memory + Disk cache issues

Post by Will - Tracker Supp » Tue Aug 29, 2017 2:47 pm

Hi Timur,

Have just heard back from the developer (he's back from his holiday) and an option is being added to control the lifespan of cached data, so this should help. It should be implemented for the next release, if all goes well!

Cheers,
If posting files to this forum, you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded.
Thank you.

Best regards

Will Travaglini
Tracker Support (Europe)
Tracker Software Products Ltd.
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Tue Aug 29, 2017 8:18 pm

Thank you, I hope he had a relaxing holidays. That change should hopefully also include a fix for the current bug that flushes cache data as soon as 30 seconds after it has been built up.

What about the disc cache, though? What folder/path is cached data supposed to be written to? In my tests it seems practically not present at all.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Wed Aug 30, 2017 6:22 am

Since the forum seems to eat posts at the moment, here is what I asked in my last post:

Will the new user setting for memory cache also fix the issue of the cache being flushed as soon as 30 seconds after it was built up?

And what about the disc cache? In what folder/path is it supposed to be written to? It does not seem to be present at all here.

Peter 123
User
Posts: 112
Joined: Mon Jun 25, 2012 11:47 pm

Re: Memory + Disk cache issues

Post by Peter 123 » Thu Aug 31, 2017 6:59 pm

Will - Tracker Supp wrote: Have just heard back from the developer (he's back from his holiday) and an option is being added to control the lifespan of cached data, so this should help. It should be implemented for the next release, if all goes well!
I can't believe it! These are phantastic news. :D

We have discussed the matter already in this thread:
http://www.tracker-software.com/forum3/ ... 2&p=113858
("Search Speed in PDF-XChange Editor")

Just to be sure that my delight is justified, I would like to add a question too: The option will also apply to the search cache? In other words: The 10 (or 10 to 15) minutes until it is flushed will no longer be mandatory?

User avatar
Paul - Tracker Supp
Site Admin
Posts: 4943
Joined: Wed Mar 25, 2009 10:37 pm
Location: Chemainus, Canada
Contact:

Re: Memory + Disk cache issues

Post by Paul - Tracker Supp » Thu Aug 31, 2017 9:54 pm

Hi Timur,
And what about the disc cache? In what folder/path is it supposed to be written to? It does not seem to be present at all here.
That should be in what ever your user variable %TEMP% is set to. We are looking into adding a feature for V7 that will allow you to specify a custom location for this.

As to the rest of the changes, we will have to wait for Lzcat to comment, it is his domain.

hth
_________________
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards

Paul O'Rorke
Tracker Support North America
http://www.tracker-software.com

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Thu Aug 31, 2017 10:14 pm

Thanks for the information. So %temp%\PDFXeditor is the correct path then? I wonder why this is written to by the System process instead of the Editor process?
Timur wrote:While over 2.5 GB data reside in Editor's memory cache there is less than 100 MB of data (often less than 60 MB) in temp\PDFXeditor.
Anyway, there are virtually no read operations happening by neither process. And the data inside that folder is not even comparable to what resides in the memory cache, even though it should rather hold more data than a *lot* less. So from my point of view it seems broken and does not seem to be used at all.
Paul - Tracker Supp wrote: We are looking into adding a feature for V7 that will allow you to specify a custom location for this.
This might be useful to some. But more importantly, give us the option to not having it flushed over shutting down Editor, plus user manageable maximum size. It likely would make sense to not only flush the oldest data, but rather the least regularly used (with some weighting for both).

I am using big image heavy PDF files that I keep reopening dozens and dozens of times. A permanent disc cache for decoded images would do wonders for my use case. Well, at this point any properly working disc cache might help.

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13524
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Memory + Disk cache issues

Post by Tracker Supp-Stefan » Fri Sep 01, 2017 8:23 am

Hi Timur,

Thanks for your feedback!
I see a colleague from the Canadian office has sent a request to one of our devs to comment with more specific details of what is coming in V7 - and we will post that info here as soon as possible!

Regards,
Stefan

Lzcat - Tracker Supp
Site Admin
Posts: 712
Joined: Thu Jun 28, 2007 8:42 am

Re: Memory + Disk cache issues

Post by Lzcat - Tracker Supp » Fri Sep 01, 2017 11:19 am

Hi Timur.
Thanks for the information. So %temp%\PDFXeditor is the correct path then? I wonder why this is written to by the System process instead of the Editor process?
You may ask Windows developers why they did this. For disk cache we use File mapping mechanism (because it is works fast and almost transparent for program - no additional buffering, etc), and for some reasons Windows show that such files are modified by system process, not editor.
Anyway, there are virtually no read operations happening by neither process. And the data inside that folder is not even comparable to what resides in the memory cache, even though it should rather hold more data than a *lot* less. So from my point of view it seems broken and does not seem to be used at all.
Again, we use File mapping, no read/write routines called for temporary files, this is may be why you don't see reading at all. In other way if you have enough of free RAM windows often keep such data in memory, so when we try to access them no physical reading from disk is needed. If you want to see effect from disk cache - please remove most memory from your PC. If you suppose that disc cache is useless - feel free to tur it off. Choice is yours.
This might be useful to some. But more importantly, give us the option to not having it flushed over shutting down Editor, plus user manageable maximum size. It likely would make sense to not only flush the oldest data, but rather the least regularly used (with some weighting for both).
Unfortunately we will not keep cached data after you close original file - for most users it will be simply waste of CPU resources, memory and disk space. If you need to work with file continuously - don't closing it is much better solution.
Just to be sure that my delight is justified, I would like to add a question too: The option will also apply to the search cache? In other words: The 10 (or 10 to 15) minutes until it is flushed will no longer be mandatory?
This option will apply to ALL cached data. There is no separate search cache, but we cache text for pages - this is why subsequent search request are so fast. But again, we will clear all cached data for specific file when it is closed, so if you want to search fast - do not close it until you will not need it.
HTH.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Sep 01, 2017 12:37 pm

Lzcat - Tracker Supp wrote:Again, we use File mapping, no read/write routines called for temporary files, this is may be why you don't see reading at all.
I would assume that the System process should at least register for read operations then, just as it does for the write operations to the cache directory? It does not, and the simple answer to why it does not is that the data does not seem to be present on the disk.
In other way if you have enough of free RAM windows often keep such data in memory, so when we try to access them no physical reading from disk is needed.
As I reported earlier, there hardly is any data present in Editor's cache directory that could be read. Less than 100 mb of disk cache data even while the memory cache peaks over 4000 mb.
If you want to see effect from disk cache - please remove most memory from your PC.
I went even further:

- Allocated almost all free memory as private memory to applications (HCI Memtest + X-Change Editor + background processes).
- Build up over 1000 mb of memory cache within Editor.
- Flushed the Windows write cache to SSD via Sysinternal's "Sync" application to make sure that all disk cache data was committed to the drive.
- Reset the Windows RAM cache to zero (0) via Sysinternal's "RamMap" application (Empty Standby List).
- Checked size and read access of PDF Editor's cache directory and took a screenshot for your convenience.
editor_disk_cache_bug.png
Here is the result: PDF Editor *does* read from its cache directory, but the data within the disk directory is infinitesimal compared to the real decoded image data of the PDF file. As a result there is no performance benefit by using the supposed disk cache, simply because the necessary data does not seem to be present on the disk!
If you suppose that disc cache is useless - feel free to tur it off. Choice is yours.
So I have the choice between turning on a function that is not working or turning off a function that is not working?! Since I find a working disk cache very useful I would prefer a third option, turning on a function that does work as its supposed to do.
Unfortunately we will not keep cached data after you close original file - for most users it will be simply waste of CPU resources, memory and disk space.
Web-browsers and graphic drivers keep cached data on the disk all the time. No one would think of this as a waste of resources, because that is why we users buy fast and big disks/SSDs in the first place. Having the CPU decode the same images over and over again is a much bigger waste of resources (paid for electricity being one of them). If any users find this useless than give them the option to turn it off, or give other users (including me) the option to turn it on.
If you need to work with file continuously - don't closing it is much better solution.
How is keeping my PC running for weeks and months less of a waste of resources, all just to keep PDF Editor from deleting its disk cache files? Please do the sensible thing here and just give us an option to keep Editor from flushing the disk cache to zero on every exit. Waiting for Editor to decode image files over and over again costs more of my time (and thus money) than having a few GB of my SSD filled with cache files!

User avatar
Tracker Supp-Stefan
Site Admin
Posts: 13524
Joined: Mon Jan 12, 2009 8:07 am
Location: London
Contact:

Re: Memory + Disk cache issues

Post by Tracker Supp-Stefan » Fri Sep 01, 2017 1:42 pm

Hi Timur,

I've asked Victor to share his further comments on your above post!

Regards,
Stefan

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Sep 01, 2017 1:44 pm

I went another step further and assumed that most of Editor's memory cache not only includes the decoded images of the PDF file, but also the completely rendered pages. This assumption makes sense, because caching the whole file uses over 7 GB of memory cache, much more than the total sum of all images included.
editor_memory_cache_filled.png
editor_memory_cache_filled.png (5.18 KiB) Viewed 3990 times
It would be great if this data was cached to disk as well, preferably over different sessions of Editor. But let's just concentrate on the pure decoded image data.

For that I extracted all images within my test file to disk via PDF Tools. The total size of all images extracted to BMP amounts to 464 mb (1:1 pixel size), as lossless JPEG 2000 the total size if 95 mb, as 95% quality JPG the total is 1000 mb. The resulting disk cache size was about 90 mb, far less than the sum of all decoded (BMP) images.

The images only use 25 mb space in the original PDF file, suggesting that they have been JPG compressed at lower quality settings. When I optimize them to ZIP via Editor their size blows up to 190 mb, which corresponds to the same size as compressing the BMP files via ZIP (using 7Z as ZIP compressor).

Then I flipped through *all* 578 pages of said PDF file using synchronous page rendering (Two Pages view at 130%). Every time a medium image was present on a page (on top of the ever present background image) there was a short lag, every time a larger image was present on a page there was a longer lag. The page build-up lag seems to be the same regardless of whether the images are saved as JPG or Flate/ZIP within the PDF file, lossless JPEG 2000 makes a bit of a difference. I can flip through the BMP and JPG experiencing the same low lag in Faststone image viewer, for the lossless JPEG 2000 files the lag is considerable.

This leads me to believe that either JPG/ZIP decoding is slower than it could be or page rendering makes the bulk of processing and thus Editor would really benefit from better multi-threading for rendering in synchronous rendering mode (if even possible in synchronous mode).

Anyway, I provided as much data as I could to help you look into this. If the bulk of my wait times really comes from rendering and not from decoding then it likely doesn't even matter to me personally. Still it's strange that the disk cache is so much smaller than the decoded images, so maybe it's worth taking a look into this for other users.

Peter 123
User
Posts: 112
Joined: Mon Jun 25, 2012 11:47 pm

Re: Memory + Disk cache issues

Post by Peter 123 » Fri Sep 01, 2017 1:47 pm

Lzcat - Tracker Supp wrote:
Just to be sure that my delight is justified, I would like to add a question too: The option will also apply to the search cache? In other words: The 10 (or 10 to 15) minutes until it is flushed will no longer be mandatory?
This option will apply to ALL cached data. There is no separate search cache, but we cache text for pages - this is why subsequent search request are so fast. But again, we will clear all cached data for specific file when it is closed, so if you want to search fast - do not close it until you will not need it.
Hello Victor,

thank you for your reply and thanks to all the people at Tracker Software who supported and finally implemented this solution. I am very happy with it. :D

I understand Timur's request who wants to go even further:
Timur Born wrote:Please do the sensible thing here and just give us an option to keep Editor from flushing the disk cache to zero on every exit.
I would like this too - it would be (for me) the perfect solution. But if this will not be implemented (for the reasons explained by Victor), it is also o.k. for me. I think the decisive, the most important step is done with the option as it is planned for the next release: cache will not be flushed as long as I do not close the file. Thanks again for this!

Lzcat - Tracker Supp
Site Admin
Posts: 712
Joined: Thu Jun 28, 2007 8:42 am

Re: Memory + Disk cache issues

Post by Lzcat - Tracker Supp » Fri Sep 01, 2017 3:15 pm

Hi Timur.
Have you ever read about windows functions such as CreateFileMapping, MapViewOfFile and so on? Please note that there is a lot of technical information related to this, and not all things are so obvious as you think. If you are using File mapping windows case is not used at all, and data from disk is directly mapped into memory, and all read/write operation are hidden deeply into OS core, so there is no way to control them using any utilities.
As I reported earlier, there hardly is any data present in Editor's cache directory that could be read. Less than 100 mb of disk cache data even while the memory cache peaks over 4000 mb.
There is no much data stored to disk, because it is really slow, and we prefer to keep as much data as possible into memory. All we are storing into disk is some fonts data to prevent frequent stream decoding (again most used data is stored into memory), modified file data, and some images. Everything else is stored into memory only, and this is main part of Editors cache. Regarding images - small are not stored into disk, only larger one, and even image is stored into disk cache because of file mapping mechanism and because of disk cache is temporary file windows prefer to keep that file in memory (if possible, which is your case).
As a result there is no performance benefit by using the supposed disk cache, simply because the necessary data does not seem to be present on the disk!
Again, this is for your situation only. Please run your tests on PC with 2GB of physical memory and use 32-bit Editor, and you will be surprised.
So I have the choice between turning on a function that is not working or turning off a function that is not working?! Since I find a working disk cache very useful I would prefer a third option, turning on a function that does work as its supposed to do.
Function is working, but it is working other way than you expect. To see benefit of image caching you should render it several times with different zoom (to avoid caching of rendered pages, which is used at first if possible). If you turn off image caching to disk at some point you will note that second rendering of previously used images is slower than with disk caching is turned on. But please note that memory caching cannot be turned off, so you will need to minimize memory used by Editor. Yes, this situation far from you usage scenario, so do not forget to change settings back.
How is keeping my PC running for weeks and months less of a waste of resources, all just to keep PDF Editor from deleting its disk cache files? Please do the sensible thing here and just give us an option to keep Editor from flushing the disk cache to zero on every exit. Waiting for Editor to decode image files over and over again costs more of my time (and thus money) than having a few GB of my SSD filled with cache files!
Have you heard of sleep and hibernation? Using them you may not close your programs weeks or even more :) Ok, this was a joke. But remember, in every joke there is a share of the joke, so using hibernation you may keep programs "running" without consuming electricity.
Regarding to keep decoded images cache between Editor sessions - it may be good for you, but it is waste of resources for most people who not working with very limited set of unchanged files. Because if you change PDF file it is very complicated to track to which image this cache part correspond (and in case of modifying file in any other program except Editor it will be not possible to track). And yes, in most cases speedup effect is not worse to a lot of coding and disk space.
I went another step further and assumed that most of Editor's memory cache not only includes the decoded images of the PDF file, but also the completely rendered pages. This assumption makes sense, because caching the whole file uses over 7 GB of memory cache, much more than the total sum of all images included.
Finally you found that we cache not only decoded images :) In most cases rendering of PDF page is very expensive, so yes, we cache rendered pages. You may see this when scrolling document forward/backward - to see page (or it part) first time you will need to wait some time (depending on page content), but second time it will be shown much faster, especially on complicated documents.
Still it's strange that the disk cache is so much smaller than the decoded images, so maybe it's worth taking a look into this for other users.
Nothing strange at all. For example we have document with two pages, each have only one image on it. First page has image with decoded size 2000kb (for example grayscale image with size1920x1080), second - only 100kb (for example black&white image with size 1280*720). When you open first page in fullscreen mode on FullHD monitor (resolution is 1920x1080) you will get less than 2Mb of disk cache and about 7.9MB of rendered page cache. For second page you will get 100 kb of disk cache and same 7.9Mb of page cache. If you are using 4k monitor disc cache will have same size, but page cache for each page will be 31.6Mb! In fact for supplied images we will not use disk cache at all, so all will be in memory.
Hope my answers will clarify some thing about caching.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Sep 01, 2017 4:20 pm

Peter 123 wrote:I would like this too - it would be (for me) the perfect solution.
I would happily allocate 50 gb SSD space just for PDF Editor's persistent cache. Consider that my *single* file example already used 7.5 gb RAM cache and most of my files are filled with text and images and little empty spaces. Every time I open them I have to watch pages being rendered again, usually on a single core (aka 6% total CPU load). In synchronous mode some pages leave me waiting over a second, in asynchronous mode I get a blank/white page blinking at me for the same amount of time.

This is on a modern and overclocked Ryzen 1800X system connected to a 2560 x 1600 display. Other PDF viewers are even slower, so I am happy about Editor's existence and thus paid for its use. ;)
Last edited by Timur Born on Fri Sep 01, 2017 5:29 pm, edited 2 times in total.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Fri Sep 01, 2017 5:28 pm

Thanks for the explanations and taking the time! It's well appreciated.
Lzcat - Tracker Supp wrote:If you are using File mapping windows case is not used at all, and data from disk is directly mapped into memory, and all read/write operation are hidden deeply into OS core, so there is no way to control them using any utilities.
Like I wrote, once I forced the Windows cache to be emptied I saw a larger read operation on the disk cache file. But the file is so small that it fits entirely into the Windows cache again, which is rebuilt within seconds. But that's not the culprit here, the culprit is that there is so little data to read from.
There is no much data stored to disk, because it is really slow, and we prefer to keep as much data as possible into memory. All we are storing into disk is some fonts data to prevent frequent stream decoding (again most used data is stored into memory), modified file data, and some images. Everything else is stored into memory only, and this is main part of Editors cache.
The whole discussion would not have come up if the memory cache wasn't bugged to the point where it flushed every 30-120 seconds. When that happened I expected the disk cache to come to the rescue and speed things up, but alas, it does not. On my PC it makes no difference if the disk cache is present or not, a freshly opened file takes the same (noticeable) time to render pages as a disk cached file that has its memory cache flushed.
Regarding images - small are not stored into disk, only larger one, and even image is stored into disk cache because of file mapping mechanism and because of disk cache is temporary file windows prefer to keep that file in memory (if possible, which is your case).
In my last test case my memory was filled to the top and Editor kept flushing its own memory cache (I had to quickly use print screen to catch a moment with filled Editor cache). But the "small images are not stored on disk" likely is the culprit here. 350 of my 465 mb of test images are stored in files smaller than 4 mb, I guess none of these have been written to the disk cache.
Again, this is for your situation only. Please run your tests on PC with 2GB of physical memory and use 32-bit Editor, and you will be surprised.
No need to, Editor flushes its memory cache regularly, often within 30-120 seconds, so I know what rendering a page without memory cache feels like. And I know that it takes the same amount of time as rendering the same page after a fresh restart of Editor, despite me using a SSD.
Function is working, but it is working other way than you expect. To see benefit of image caching you should render it several times with different zoom (to avoid caching of rendered pages, which is used at first if possible). If you turn off image caching to disk at some point you will note that second rendering of previously used images is slower than with disk caching is turned on.
No, it makes no difference. It takes considerably longer to render a page that is not within the memory cache, but it does not render any faster because of the disk cache. Which is why I started the whole disk cache discussion to begin with. Seeing how only a small fraction of decoded image data is written to the cache (about 100 out of 465 mb) I see why this is the case.

I don't know whether decoding or rendering takes longer (I suspect the latter, especially given the amount of memory needed). What I know is that some pages make me wait 1-2 seconds while my total CPU load never exceeds about 6.25%. Even though I see (Process Explorer) the load being distributed over several threads (mostly 4) and cores the sum still corresponds to a total load of only a single logical core (16x 6.25% = 100%). So there is some bottle-neck keeping Editor from making more use of my CPU and I am not convinced that this is image decoding. The memory cache is the one thing that keeps PDF operation smooth, but memory is limited (and currently bugged). So a disk cache that properly caches as much data as possible (not just some big images) and reloads it into memory upon restart/reuse would speed things up.
But please note that memory caching cannot be turned off, so you will need to minimize memory used by Editor. Yes, this situation far from you usage scenario, so do not forget to change settings back.
I tested this with only a 100 mb memory cache and spammed my memory silly with data, still makes no difference. The disk cache just does not hold enough data to be of much use, the bottle-necks seem to be elsewhere on a fast PC such as this one.
Have you heard of sleep and hibernation? Using them you may not close your programs weeks or even more :) Ok, this was a joke. But remember, in every joke there is a share of the joke, so using hibernation you may keep programs "running" without consuming electricity.
Unfortunately standby and hibernation are bugged in current UEFI versions of Ryzen systems, so it's not an entirely feasible solution. And then there are those days where I need my memory for something else (large Photoshop edits come to mind), which in turn will flush Editor's memory cache all the same.
Regarding to keep decoded images cache between Editor sessions - it may be good for you, but it is waste of resources for most people who not working with very limited set of unchanged files.
There is no waste if it's an option. Everyone can turn it on or off just as they please. And I suspect that most people who use Editor for reading (not editing) do so because they need the extra performance for their more complex files. Else they could just stay with Adobe Reader. So anything that improves performance is a good thing, especially if optional.
Because if you change PDF file it is very complicated to track to which image this cache part correspond (and in case of modifying file in any other program except Editor it will be not possible to track). And yes, in most cases speedup effect is not worse to a lot of coding and disk space.
I see the point of managing changing files, but even something as simple as date + size changes would help to keep it in check. A hash based cache/database system would be the next step. Nothing wrong with caching a changed file completely anew if this opens the possibility of using old cache data for all those files that never change (which often are the biggest and most complex ones). Some of us will be delighted once pre-rendering is in place. Of course that doesn't help so much with quick searches of newly opened files.
In most cases rendering of PDF page is very expensive, so yes, we cache rendered pages. You may see this when scrolling document forward/backward - to see page (or it part) first time you will need to wait some time (depending on page content), but second time it will be shown much faster, especially on complicated documents.
Yes, I do see this. And it makes me cringe that I still have to watch a 16 logical core behemoth CPU building up pages. If this cannot be improved by multi-threading then it needs improvement by caching. "In most cases rendering of PDF page is very expensive" sound like a perfect reason to write those finished rendering to a (optional) disk cache.
First page has image with decoded size 2000kb (for example grayscale image with size1920x1080), second - only 100kb (for example black&white image with size 1280*720). When you open first page in fullscreen mode on FullHD monitor (resolution is 1920x1080) you will get less than 2Mb of disk cache and about 7.9MB of rendered page cache.
But that was not what I reported. My disk cache is less than 100 mb in size while the decoded images are 465 mb in size (at 100%). I extracted all images as BMP via PDF Tools, their sum is bigger than what is cached to disk. According to your earlier explanation this is likely because small files are not cached at all.

Peter 123
User
Posts: 112
Joined: Mon Jun 25, 2012 11:47 pm

Re: Memory + Disk cache issues

Post by Peter 123 » Sat Sep 02, 2017 3:17 am

The level of your discussion is by far too high that I could contribute something substantial. :wink: But I would like to support a remark by Timur that refers to Victor's following statement:
Lzcat - Tracker Supp wrote:Regarding to keep decoded images cache between Editor sessions - it may be good for you, but it is waste of resources for most people who not working with very limited set of unchanged files. [...]
Timur Born wrote: There is no waste if it's an option. Everyone can turn it on or off just as they please.
In my case images do not play any role (my main PDF files contain only text) but I have a similar situation as described in one of the above postings by David. P:
David.P wrote: [...] I would like to add that today I am working with a typical ~1000-page PDF again. Searching this PDF takes about 30 seconds in PDF-XChange Editor -- initially, or after the text cache has been flushed (which seems to happen about every 10-15 minutes). Searches with text cache active however take less than 1 second (i.e. are instantaneous), so it can be said that keeping the text cache in memory can speed up document search by a factor of about 100.
Concerning myself, one of my main PDF-files is a dictionary which consists of even some thousand pages and the search speed (for the first search in a session) are about the same 30 seconds (a phantastic speed anyway!). Not closing the file (as suggested above by Victor) is a very good solution and (as I already mentioned) absolutely o.k. for me in order to keep the speed of "less than 1 second". And the 30 seconds "delay" when occasionally I close the file (for whatever reason this may be necessary or useful) and open it the next time are also completely acceptable.

But nonetheless - if non-keeping the cache between two sessions of the XChange Editor happens only in the interest of the users (no waste of resources, as explained by Victor) I would join Timur's argument: If it were an option, every user could decide by himself if he wants to keep or to flush the cache when finishing a session. - Of course I have no idea how difficult and laborious it would be for the developers to implement such an option. If this is too hard work, it is surely not worth the time and energy for something that would be of importance only for a minority of users. But if - on the other hand - such an option were something relatively simply to realize, please consider to do so.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Mon Sep 04, 2017 9:52 pm

I can understand if there is not enough man-power to implement functions that are seen as "exotic" by the developers. I do not follow the "wasted resources" argument, though. Not only is harddrive/SSD space cheap as never, but at the same time that only 100 mb is written to my cheap and big SSD there is 7.5 gb used of my expensive and relatively small RAM.

The latter is optional and user manageable, so it's not a problem but a feature. The former is a "waste of resources" in the sense that my precious resources are not used to the extend they are meant to be used (and have been paid for in hardware cost).

Lzcat - Tracker Supp
Site Admin
Posts: 712
Joined: Thu Jun 28, 2007 8:42 am

Re: Memory + Disk cache issues

Post by Lzcat - Tracker Supp » Tue Sep 05, 2017 10:14 am

The whole discussion would not have come up if the memory cache wasn't bugged to the point where it flushed every 30-120 seconds.
So please pause discussion until next build is released - it should fix cache behavior.
I don't know whether decoding or rendering takes longer (I suspect the latter, especially given the amount of memory needed). What I know is that some pages make me wait 1-2 seconds while my total CPU load never exceeds about 6.25%. Even though I see (Process Explorer) the load being distributed over several threads (mostly 4) and cores the sum still corresponds to a total load of only a single logical core (16x 6.25% = 100%). So there is some bottle-neck keeping Editor from making more use of my CPU and I am not convinced that this is image decoding. The memory cache is the one thing that keeps PDF operation smooth, but memory is limited (and currently bugged). So a disk cache that properly caches as much data as possible (not just some big images) and reloads it into memory upon restart/reuse would speed things up.
Both decoding and rendering may take a long time, it depends on PDF content. There was explain about multithreaded rendering in other thread. All things was explained there, about CPU load too. Regarding to disc cache: disk speed is very limited (yes, even for SSD), and have very high latency in case of HDD. Of course SSD have no much problems width data reading in several treads, but in case of HDD performance is terrible and in most cases it is faster to decode image again than read it from disk cache. Same with pre-rendered pages - in most cases it is faster to render page again that read data from HDD. Ok, you have SDD, but there is two problem with them: free space (many users have not so large SDD, if any) and write resource. As I told before for FullHD monitor each page in fullscreen mode will take about 7.9Mb of memory. Reading of 1000 pages per day will require about 7.9Gb of disk resource. Not so big deal, but what if you have a lot of documents which you are using from time to time? For example some documentation with 200 000-300 000 pages, which you are not viewing often? Or even worse, you are working with documents from customers, which you should process and forget about them for a long time, until you need to check something, or even forever? For such cases using disk cache is real waste of resources (disk space, time to write data to disk, time to check disk cache, and so on). And I'm afraid that such usage scenarios are more frequent. And yes, for most documents page rendering time is not several seconds, but much less than a second, and in synchronous page rendering mode they are not noticeable at all (however I will recommend to use Auto for synchronous page rendering mode to prevent Editor from stopping responding on heavy PDF pages).
So finally: disc caching working as I described earlier, and we won't change this in nearest future unless there will be serious need to do this. Memory caching is already changed (hope it will satisfy most your needs), please wait for next build. About rendering performance (and low CPU load on multicore CPU) - we will se what can be done, but do not expect changes soon.
HTH.
Victor
Tracker Software
Project manager

Please archive any files posted to a ZIP, 7z or RAR file or they will be removed and not posted.

Special
User
Posts: 129
Joined: Fri Jan 31, 2014 9:24 pm

Re: Memory + Disk cache issues

Post by Special » Tue Sep 05, 2017 5:13 pm

For what its worth, I'm very happy with the current performance of PDF-XChange Editor, I absolutely hate disk caching and try to avoid it whenever possible, not just in PDF programs but in almost anything, such as shader caching in Nvidia Drivers, as the performance is always terrible compared to when utilizing system memory instead, the biggest thing that this Editor has over say the Viewer was the new Performance Option > "Do not use disk to cache decode images", this alone has made a world of difference in performance for me, and I'll hunt whoever down who removes this option. I would also dislike having the Editor start writing huge temp 1-10GB files on my system again, which it used to before I discovered the "Do not use disk to cache decode images" check box.

Timur Born
User
Posts: 617
Joined: Tue Jun 26, 2012 1:50 pm

Re: Memory + Disk cache issues

Post by Timur Born » Tue Sep 05, 2017 9:43 pm

Lzcat - Tracker Supp wrote:
The whole discussion would not have come up if the memory cache wasn't bugged to the point where it flushed every 30-120 seconds.
So please pause discussion until next build is released - it should fix cache behavior.
I can do so, but my point was not about the memory cache behavior itself, but that the bugged behavior made me aware of the missing performance benefit of the current disk cache mechanism. Once data is flushed out of the memory cache - for whatever reason - I expected the disk cache to have more of an impact. (Now) Knowing that it only holds part of the decoded images and not the bulk of rendering data these results make sense now.
Not so big deal, but what if you have a lot of documents which you are using from time to time? For example some documentation with 200 000-300 000 pages, which you are not viewing often? Or even worse, you are working with documents from customers, which you should process and forget about them for a long time, until you need to check something, or even forever? For such cases using disk cache is real waste of resources (disk space, time to write data to disk, time to check disk cache, and so on).
This is why I suggested that both actuality and frequency (!) should be weighted. If some obscure document is only opened a few times per year it has less priority in the cache than more often used documents. And once the disk cache hits is limit - user configurable - it cleans up itself, so no data is "forgotten" there.
And I'm afraid that such usage scenarios are more frequent.
Which is no problem if disk cache usage is optional. Everyone can choose what fits their scenario. No waste happening for those people who don't need/like it, while other people can make better use of their expensive hardware.
And yes, for most documents page rendering time is not several seconds, but much less than a second, and in synchronous page rendering mode they are not noticeable at all
I use some documents where synchronous page rendering displays a blank/white page for up to a second with pages filled by images. Other pages may only blink white shortly, which still isn't too eye friendly and definitively "noticeable". And lag is always noticeable when it happens.
(however I will recommend to use Auto for synchronous page rendering mode to prevent Editor from stopping responding on heavy PDF pages).
What does "Auto" rendering mode do exactly, under what circumstances does it switch from synchronous to asynchronous automatically?

On a side note: Disabling "Do not use disk cache for decoded images" does not delete the cached data right away. Only once the file is closed is the data deleted from disk.

Thanks for the effort and replies!

Peter 123
User
Posts: 112
Joined: Mon Jun 25, 2012 11:47 pm

Re: Memory + Disk cache issues

Post by Peter 123 » Sat Dec 16, 2017 2:50 am

Lzcat - Tracker Supp wrote:[...] until next build is released - it should fix cache behavior.
[...]
Memory caching is already changed (hope it will satisfy most your needs), please wait for next build.
Concerning my needs, with version 7 all works fine now. :D

See my description here: https://www.tracker-software.com/forum3 ... 68#p119268

John - Tracker Supp
Site Admin
Posts: 8202
Joined: Tue Jun 29, 2004 10:34 am
Location: Vancouver Island - Canada
Contact:

Re: Memory + Disk cache issues

Post by John - Tracker Supp » Fri Dec 22, 2017 10:32 am

Excellent news - thanks.
If posting files to this forum - you must archive the files to a ZIP, RAR or 7z file or they will not be uploaded - thank you.

Best regards
Tracker Support
http://www.tracker-software.com

Post Reply