Memory Leak...

[jwhitetoo]

Hello again,

Just updated to PDFX-Change Viewer build 1.0.0034 and still have the same issue. Here we go....

ACROBAT:
Open file in Acrobat (file is about 5mb in size). Uses about 42mb of memory. If I scroll real fast through the document I can get it to climb up to just over 50mb and when I stop scrolling it starts to drop back down.

PDFX-CHANGE VIEWER
Starts off using less memory than Acrobat, but as soon as I start to scroll through the document it starts to climb. When it gets past approx 100-125mb memory consumption accelerates and I've taken it up to 400mb and could easily keep going. With every scroll of the mouse memory consumption climbs. If I stop scrolling memory consumption just sits there. Start scrolling again, memory consumption climbs.

This has memory leak written all over it and I suspect that a lot of other posters that have complained about this just didn't realize what was happening. I took a video of my test and can send it to you outside of the forum if you'd like (don't want to post it on the forum).

This needs to be fixed ASAP!

Thank you,

James

[Bhikkhu Pesala]

I can reproduce the problem.

To fix it as soon as possible, minimize PDF-XChange and then maximize it again. If you're switching away from PDF-XChange to use another program, minimizing it will reduce memory use to about 1,200 Kbytes.

If you have 1 Gbyte of memory or more, don't worry about using 400 Mbytes for the program that you're currently working in. Memory is there to be used.

Try not to make silly demands about what must be fixed. I am sure that the developers can work out their own priorities. They have many things that they are trying to fix and improve, and release new versions about once a fortnight.

IMO anything that causes the program to crash would be a top priority. Next would be fixing broken features. Then performance improvements would be third in line, then new features would be next in preference to reducing memory usage, because memory usage has no effect on my experience in using PDF-XChange, (until such time as my PC runs out of free memory, then it might have a serious impact on performance).

[Lzcat - Tracker Supp]

PDF-XChange Viewer can use a lot of memory for caching, and this is not a leak or bug - this is by design.

There are a lot of documents where caching will give a good perfomance boost.

Did you see Perfomace tab in Viewer Preferences?

There you can set how much memory the Viewer should be allowed to use in % terms. By default it will use up to 25% of the available physical memory since build 31, and 50% for previous builds, so if you have 4Gbyte of physical memory - yes, the Viewer can use up to 1GByte, if you do not tune it specifically to your own prescribed settings.

Also, if you do not use the Viewer for a long time (about 10 minutes for now) it will free almost all cached data.

Hope that helps.

[jwhitetoo]

All,

Sorry for the delayed response. I was traveling when I posted that and going about 18 hours a day...

Okay, let me respond to a few comments and then I'll make my case:

Bhikkhu

minimizing it will reduce memory use to about 1,200 Kbytes

Thanks! This is much easier than closing/opening documents!

Bhikkhu

If you have 1 Gbyte of memory or more, don't worry about using 400 Mbytes for the program that you're currently working in. Memory is there to be used.

I guess if you have 1 Gbyte of RAM (I have 1.5) and PDF-XChange Viewer is the only app you have running OR you have other apps running but they don't consume and hold more than there fair share of memory for 10 minutes, then you have a point.

Bhikkhu

Try not to make silly demands about what must be fixed. I am sure that the developers can work out their own priorities. They have many things that they are trying to fix and improve, and release new versions about once a fortnight.

I'll make the case below why demands probably aren't so silly, but in general, YES I agree with you. BTW, congratulations b/c you are the second person I've run into that uses the word "fortnight". LOL If this trend continues I may start using it myself.

Bhikkhu

IMO anything that causes the program to crash would be a top priority. Next would be fixing broken features. Then performance improvements would be third in line, then new features would be next in preference to reducing memory usage, because memory usage has no effect on my experience in using PDF-XChange, (until such time as my PC runs out of free memory, then it might have a serious impact on performance).

See comments below.

Victor

There are a lot of documents where caching will give a good perfomance boost.

I imagine so but in testing the pdf's that I looked at against Acrobat Reader, I didn't see any noticeable performance difference. Certainly not any that justified a potential 87% of additional RAM to be consumed. For reference, my system is a Thinkpad T60, Intel Core Duo (T2400) with both core's at 1.83GHz on 1.5GHz of RAM and in general this thing is pretty darn fast.

Victor

Did you see Perfomace tab in Viewer Preferences?

There you can set how much memory the Viewer should be allowed to use in % terms. By default it will use up to 25% of the available physical memory since build 31, and 50% for previous builds, so if you have 4Gbyte of physical memory - yes, the Viewer can use up to 1GByte, if you do not tune it specifically to your own prescribed settings.

Also, if you do not use the Viewer for a long time (about 10 minutes for now) it will free almost all cached data.

This helped a lot, thanks!



Okay, now for my follow-up thoughts:
For the sake of context, I've been using PDF-XChange Viewer for quite a while now, tested PDF-XChange Pro 3.x and purchased and now use PDF-XChange Pro 4.x. Also, I use Viewer and Pro A LOT, almost as much as I use Microsoft Outlook. I really like the products but most importantly I like the level of support and attention that Tracker Products provides to it's customers. In short, my comments are not intended to be derogatory but rather, are to be taken as constructive criticism.

And with that out of the way...

One of the reason's I am interested in Tracker products is to be able to offer them to my customers who will be accessing their data and applications via Microsoft Terminal Services. For those unfamiliar, Terminal Services allows you to serve virtual Windows desktops to say 50 users from one server. I know from reading other posts that PDF-XChange Pro is used in several larger Terminal Server/Citrix installations. Given that Viewer is new, I imagine they used Pro to print and manipulate documents while using Acrobat Reader to view documents. However, given that a lot of the Pro functionality is going to be moved over to "Viewer Pro", I suggest that extra attention be paid to what is next.

Any app written to Microsoft's specifications and which earn's the official Windows logo should run on Terminal Services as well any regular Windows desktop. Part of this means playing fair with memory consumption. So if you have 50 users on a Terminal Server that has the maximum amount of RAM that Windows with Terminal Services can handle (too complicated for this post), you've got 4Gb of RAM to play with 2Gb for the kernel and 2Gb for user apps. If 10 of those users are using PDF-XChange Viewer, that one little "lightweight" app will consume everything that the server has to offer. Potential work arounds - use third party app to control how much memory PDF-XChange Viewer can take, create custom Active Directory Group Policy or custom MSI package to set and lock the settings under "Viewer Preferences". Since even with conservative preference settings PDF-XChange Viewer still consumes more than it's fair share of RAM and doesn't return it back within any sort of reasonable amount of time, I think only the third party app method would work and who knows how PDF-XChange Viewer would react to this.

So in closing, I would ask that you reconsider how PDF-XChange Viewer manages memory. I first noticed the excessive memory consumption when it caused performance problems on a system with 1.5Gb of RAM with a lot of apps and documents open but I imagine that most average desktop users will not notice it. However, the way it's architected now, I cannot offer viewer to my customers in our Terminal Server environment and I imagine that Tracker's large Terminal Server/Citrix customers are going to have issues as well, especially when they are forced to use "viewer" when the "Pro Viewer" is released.

Thanks for taking the time to read this,

James

[Lzcat - Tracker Supp]

I imagine so but in testing the pdf's that I looked at against Acrobat Reader, I didn't see any noticeable performance difference.

Ok, here is one of them: http://download.microsoft.com/download/ ... _LORES.pdf (a bit less than 1 Mbyte). Try scroll the page using the Hand tool.

Caching mechanism can be revised in the future, as we refine the caching model.

[jwhitetoo]

Ok, here is one of them: http://download.microsoft.com/download/ ... _LORES.pdf (a bit less than 1 Mbyte). Try scroll the page using the Hand tool.

Okay, that was pretty impressive.

Caching mechanism can be revised in the future, as we refine the caching model

I'm wondering if the majority of users even deal with this type of document. My guess is they are a minority based on my own experience (12 years of consulting) and by the fact that Acrobat Reader obviously isn't tuned to handle them either. I know for my customers, their needs are pretty much straight business documents and there the differences in performance is negligible.

I'm thinking that a good option would be to have two memory/performance modes. It would default to "normal mode" where it more or less emulates a typical Windows app like Acrobat Reader and also have an "aggressive mode" where it behaves as it does today. "Aggressive Mode" would be for users that work with documents such as the one in the link you provided. I would want the the setting to ultimately appear as a non-hex registry key so that I can lock it down (alter the security on that key) and force users to choose the one I want.

Thoughts?[/quote]

[jwhitetoo]

I know for my customers, their needs are pretty much straight business documents and there the differences in performance are negligible.

I should have added - but the feature set and ease of use with PDF-XChange Viewer is WAY better.


Okay, the real reason for this post:
Is Viewer Pro going to spell the immediate end of PDF-Tools? I am hoping not, at least not for the next version or two. I won't be able to use "Viewer" pro or free in a terminal services environment but some users will still want that functionality so PDF-Tools would be the way to give it to them.

Thanks again,

James

[jwhitetoo]

Hello again,

Any chance we could get a statement of direction on some of the above?

Thank you,

James

[Ivan - Tracker Software]

no, Viewer PRO doesn't mean the end of PDF-Tools. Maybe in long long perspective it is, but not so soon.

[John - Tracker Supp]

Also there are some functions that are used to 'batch' convert files and this may be better suited to an interface like PDF-Tools uses - rather than the Viewer interface.

[jwhitetoo]

Fantastic!

How about on the topic of memory utilization?

[John - Tracker Supp]

For now - we are satisfied that we for the majority, the current model is the best we can achieve until a major rewrite is in progress - other than refinining the Caching as we go.