Huge drain on system resources

[TMiB03]

I seem to have an issue, when viewing pdfs in Firefox, a new process is started (PDFXCview.exe) that continues to ramp up and use more and more memory, slowing my system to a crawl (AMD Quad Core 3.4, Windows 7-64 bit, 8 gb ram). It did not happen until I upgraded to the new beta version 2.5. I'll be uninstalling it until the issue is resolved. Just while setting here, writing the post, and keeping an eye on system resources, I have a pdf object open on 2 tabs within FireFox 3.6.12, and have been watching the memory use climb from 200,000k, to at this point well over 1.2million K, while all the time using 25% of my cpu, 1.3, 1.4.

speaking of the new version, 2.057 was not uninstalled when the new version was installed, so both version still exist on my system.

[TMiB03]

After having uninstalled both 2.057 and 2.5, restarting my machine, reinstalling 2.057 and reopening the exact same web pages, PDFXCview.exe is not using any CPU as I type this message, and is holding steady around 46,000 k for the two pages I have open.

Here is what is open in Fire Fox:
https://forum.pdf-xchange.com/ ... =35&t=9412
http://mdotwas1.mdot.state.mi.us/public ... m0040a.pdf
http://mdotwas1.mdot.state.mi.us/public ... m0110a.pdf
http://mdotwas1.mdot.state.mi.us/public/tands/plans.cfm

[m.orthmann@poyry.com]

Hi,

I can confirm this issue, had this issue after the update to Build 188 also. But, Firefox worked still with an OLD version of plugin DLL. After repairing this manually everything is fine. Just check what version of PDF-XChange is displayed within the browser.

Yours Michael

[TMiB03]

it is using the version 2.057 plug-in. perhaps it is all linked to the fact that 2.057 was not automatically uninstalled as previous versions have been while installing the new version.

[m.orthmann@poyry.com]

Hi,

I checked this issue again after reading your reply and i found out, when using Tabs in Firefox it is the same. When I am viewing the Tab CPU-Usage is normal, when leaving the Tab open or leaving the focus of FireFox to the next application it is going up to 50 percent (means 100% on one core). This is far away from normal activity .... this is a bug.....

Help would be appreciated.

Yours

Michael

[Stefan - PDF-XChange]

Hello Michael and TMiB03,

I made a ticket (#643) so that our dev guys could have a look at it and we will advise here shortly of any findings we have.

Best,
Stefan

[Vasyl - PDF-XChange]

Hi, Michael and TMiB03.

This bug will be fixed in the next build (upcoming). Thanks for your report.

Best
Regards

[m.orthmann@poyry.com]

Hi Vasyl,

good news to me. You and the Dev-Team are doing a great job on a great product. Thanks.

Michael

[Paul - PDF-XChange]

[mick7]

Same issue here with 2.5 build 188, had to revert to 2.057...

I would also be happy to stay informed about the progress in this case, as I like the new look and would rather use the new version . Where can I look into ticket 643 - or is this just tracker's internal code?

Best regards

Michael

[Stefan - PDF-XChange]

That's internal only ticketing system Michael,

But the issue was already located and the fix is found.
The stable release of 2.5 expected in 10-14 days will introduce it.

Best,
Stefan

[mick7]

Prima, vielen Dank!

[Stefan - PDF-XChange]

Glad I could bring the good news Michael

Best,
Stefan

[prius]

Hopefully, the new build (189) was not intended to be the solution. I just installed it and resource usage is still huge. For example, I opened a ~660K PDF file, scrolled to the end of the document, and discovered that memory usage for Viewer was in the 350MB range. Upon opening an ~8MB PDF, mem usage was close to double the previous figure (i.e. well over 650MB). FWIW.....

[m.orthmann@poyry.com]

Hi there,

for me Build 189 resolved the problem I described above. Is working as aspected

Good job....

Yours

Michael

[Stefan - PDF-XChange]

Hello Prius,

Can you please check the browser plugin's version and ensure it has updated correctly?
If you can't see the file menu in FF - open any PDF file from the web, move it with the hand tool then press F9 - this will show the "File, Edit ..." menu, and then in Help -> About you will see the build number of the browser plugin.
(it might not have been updated correctly if you had FF opened while updating).

Best,
Stefan

[mick7]

Thanks a lot - apparently this update did the job. Memory usage of the various PDFCVview.exe processes remains between 18 and 31MB when using the Firefox plugin, good work.

Best regards

Michael

[Stefan - PDF-XChange]

Thanks for confirming it's fixed for you too Michael.

So we just need to locate what is causing the problem for prius.

Best,
Stefan

[prius]

Hello Stefan,

Yes, the issue I reported actually doesn't have anything to do with the browser plugin; I'm referring to the memory usage of the Viewer itself, which version shows as 2.5 (Build 189.0)(December 6 2010;22:12:13). I am using the PRO version but I doubt if that would be the source of this issue.

Again, as an example, after I opened a couple of ~660K documents and simply scrolled to the end, I saw memory usage hitting the mid-upper 300s (i.e. 350-380MB). Starting the Viewer *without* opening a document does not present an issue; it appears to consume ~17MB (very light and very normal). For laughs, and thinking it might be something peculiar to my system, I checked the same docs with another viewer and found usage to be comparatively normal (total mem usage in the ~28-31MB range).

I'm using Windows XP/SP3 with 2.5GB RAM. Please let me know if you need any more information.

Thanks!

Hello Prius,

Can you please check the browser plugin's version and ensure it has updated correctly?
If you can't see the file menu in FF - open any PDF file from the web, move it with the hand tool then press F9 - this will show the "File, Edit ..." menu, and then in Help -> About you will see the build number of the browser plugin.
(it might not have been updated correctly if you had FF opened while updating).

Best,
Stefan

[Stefan - PDF-XChange]

Hello Prius,

Yes I see your point.
This is because of cashing I believe.
If you minimize the Viewer, the momory usage drops to just a few MB, and then when you maximize it back again - it allocates 25-30 Mb - enough to render the current page of the opened tab.

When you scroll and if you have left the momery usage to automatic - it will keep allocating memory while available to speed up consecutive readings of already visited content. but if you like in Edit -> Preferences -> Performance you can set this up to e.g. 5% (which on your system would be about 120 Mb), and the Viewer will not use more than that amount of RAM.

Best,
Stefan

[TMiB03]

I am seeing that my original issues appears to be resolved, as I am posting, they are staying right around the 48,000k mark. As to the issue Prius is having, I have another file that is open that is only causing a 67mb drain on memory, it is a 484kb file But based on my previous experience with this program it is an acceptable value as I think the program uses about 40mb just to sit there with nothing open.

[prius]

If you minimize the Viewer, the momory usage drops to just a few MB, and then when you maximize it back again - it allocates 25-30 Mb - enough to render the current page of the opened tab.

Yes, thank you, I see that indeed it does drop to next to nothing after minimizing and then to an acceptable level after maximizing.

When you scroll and if you have left the momery usage to automatic - it will keep allocating memory while available to speed up consecutive readings of already visited content. but if you like in Edit -> Preferences -> Performance you can set this up to e.g. 5% (which on your system would be about 120 Mb), and the Viewer will not use more than that amount of RAM.

Well, in Edit -> Preferences -> Performance, I'm seeing 10% as the absolute minimum level (i.e., no 5%) but that's basically okay. The scrolling issue is pretty strange, though. I can understand the 'caching content to speed up consecutive readings' concept but the actual results don't appear to comport with the concept. In other words, even when I set the memory usage to the lowest level, open and scroll all the way through a ~8.5MB file, I still can't see a difference in speed versus when I had the memory setting to "automatic". Simply put, the performance gain seems to be minimal and doesn't appear to justify such a dramatic increase in memory usage.

[Stefan - PDF-XChange]

Hi prius,

You can type in the field a smaller value than the available 10%

And for some vector heavy files the increase could be significant.
In any case, I am now discussing this with our lead developer - he told me that in fact most of this memory is cache, which is released after about a minute of idling, when you minimize the Viewer, or when the allocated memory limit is reached.

So besides the extreme case when you go through 50-60 pages in a minute, the cache should hold just 2-3 pages at a time, which would be about or less than 100MB, even with the Auto setting.

Best,
Stefan

[prius]

You can type in the field a smaller value than the available 10%

Oh yeah......never realized that. I immediately input 5%, opened a file, and all appears to be well. I believe a max of 125MB would be sufficient for my purposes but may just leave it on auto permanently. Regardless, thanks!

....In any case, I am now discussing this with our lead developer - he told me that in fact most of this memory is cache, which is released after about a minute of idling, when you minimize the Viewer, or when the allocated memory limit is reached.

Again, thanks. I set the value to "Automatic" and just noticed that, in fact, the memory *was* released after a couple of minutes. I mean, all the way down from 660MB to ~40MB. Nice.

So besides the extreme case when you go through 50-60 pages in a minute, the cache should hold just 2-3 pages at a time, which would be about or less than 100MB, even with the Auto setting.

I understand. However, for me, it's not such an "extreme case" in the sense that I view quite a lot of PDFs that contain indices at the end. If I simply grab the slider to quickly move down to the index (in order to find a page number for a topic), and then use the slider to move to the page number (or scroll to it), I find that memory usage really does spike up to a rather high level. No big deal for me, actually, since I have plenty of RAM. Anyway, something for the developers to look at, perhaps.

[John - Tracker Supp]

Thanks for the input - we will take a look around this for V3 in the new year.

cheers

[Arnold]

I had posted about this once before when I noticed how much memory was tied up when scrolling up and down a document. In order to get documents to scroll the way I want them to I have had to set the program to use synchronous mode. How does that affect the release of memory?

[Stefan - PDF-XChange]

Hello Arnold,

Synchronous mode does not affect the caching the viewer performs I am afraid, and it will keep allocating memory up to the specified allowed limit.

Best,
Stefan

[Arnold]

Okay. I just wanted to know if it works the same with synchronous on. Thank you.

[Stefan - PDF-XChange]

Gladly Welcome Arnold!

Best,
Stefan

[Defenestration]

Re. the caching issue, I have just posted a feature request for improved auto memory management in PDFXV, so that it takes into account free memory, rather than just total memory.

[Stefan - PDF-XChange]

Thanks for that Defenestration,

I will speak with the guys working on this and see what we can do.

Best,
Stefan

[Arnold]

Also memory related. If PDFX Viewer is minimized, the memory it was using is freed up. If it is minimized to the system tray it does not seem to happen. If left minimized to the system tray, does that memory ever get released? Thanks.

[Stefan - PDF-XChange]

Morning Arnold,

Yes if left in the system tray for more than a couple of minutes the memory used for cache is released, so the Viewer should drop to using 30-40Mb of memory.

Best,
Stefan

[Vasyl - PDF-XChange]

Hi, Arnold.

Also memory related. If PDFX Viewer is minimized, the memory it was using is freed up. If it is minimized to the system tray it does not seem to happen. If left minimized to the system tray, does that memory ever get released? Thanks.

We will improve memory releasing when PDFX Viewer is minimized to task bar or to system tray area. Please wait for next build.

Best
Regards

[Arnold]

Great. Thank you. I will then set PDFX Viewer to minimize to the system tray as I use it a lot.

[littlebum2002]

I have build 2.5.188, and I have the same problem. I set the viewer to use 10% of memory, and looking at the attached image, it is obviously using much more. I had a PDF open in Firefox, and one open stand-alone. Even if this goes away by minimizing (which I didn't find), I still would like to have a PDF open in one firefox tab while browsing in another and not have 93% of my memory used up. Is PDF-Xchange just not the viewer for me? Or will the recent build solve this problem?

[Stefan - PDF-XChange]

Hello littlebum2002,

There was a memory issue in build 188 with the FF plug-in.
Please update to the latest build 189:
https://www.pdf-xchange.com/product ... nge-viewer
And the 10% limit you have given would be honoured.

Best,
Stefan

P.S. You can manually input a number smaller than 10% if you want as well.