Slowing preformace issues

[bvonarx]

My version of PM seems to be running slower than usual (especially when other programs are open, mostly Outlook and Firefox, but especially Itunes) and even becomes non responsive after editing and saving as several images, any ideas as to how to speed things up?
PM version: 4.6.5
Windows XP Pro
Service Pack: 6.latest
Memory: 8 gigs
CPU: 3.20
Cache location-default
Disk cache size-512mb
Memory cache size- 200 mb
Reserve cache- 500 mb
Antivirus, antispy and defrag utilities are run weekly

[Kirk Baker]

My version of PM seems to be running slower than usual (especially when other programs are open, mostly Outlook and Firefox, but especially Itunes) and even becomes non responsive after editing and saving as several images, any ideas as to how to speed things up?
PM version: 4.6.5
Windows XP Pro
Service Pack: 6.latest
Memory: 8 gigs
CPU: 3.20
Cache location-default
Disk cache size-512mb
Memory cache size- 200 mb
Reserve cache- 500 mb
Antivirus, antispy and defrag utilities are run weekly

Get the 4.6.6 beta available in the Announcements section of the forums.

-Kirk

[Philip Goddard]

Kirk, I don't know whether the underlying problem is the same, but I myself have a very major system slowdown issue caused by PM 4.6.6, and it was happening with 4.6.5 too, but not previously, at least to an extent that got in my way.  It seems to be particularly bad with 4.6.6, and is bad enough that I'm getting tempted to revert to XnView for my photo sorting, even though PM offers some superior facilities.

The problem appears to be associated with an extremely inefficient process of rendering the thumbnails in a folder, and of rendering any larger and especially zoomed-in views. A folder containing 170 nominally 9 Mpix jpegs takes several minutes for all the thumbnails to be fully rendered (and their captions turned from red to black), and during that time PM is hogging almost all the CPU 'space' and is thus extremely slow to respond to attempts to carry on doing anything within the program during that process or indeed doing anything in any other program while I wait.

Then, when I use the zoom function for any image, once again the CPU churning resumes for something towards half a minute, so that I have to wait before I can move to the neighbouring photos.

I note that there is no parallel problem when I load such a folder (and indeed the same one) in the browser of XnView. There the browser thumbnails all render in a very few seconds, with no obstruction to my continuing to carry out actions within the program. Also, I have not had such a CPU-hogging from any other program (apart from the odd very rare situation where the whole system has become unstable - but such events are not really a feature of this system (so far!).

I'm using 32-bit Windows 7 Home Premium with all updates, with 2 Gig memory, and Intel(R) Core(TM)2 Duo CPU  E6750  @ 2.66GHz.

Is there any debug information I could get from PM to assist you in addressing this problem?

[Kirk Baker]

Philip,

Kirk, I don't know whether the underlying problem is the same, but I myself have a very major system slowdown issue caused by PM 4.6.6, and it was happening with 4.6.5 too, but not previously, at least to an extent that got in my way.  It seems to be particularly bad with 4.6.6, and is bad enough that I'm getting tempted to revert to XnView for my photo sorting, even though PM offers some superior facilities.

The problem appears to be associated with an extremely inefficient process of rendering the thumbnails in a folder, and of rendering any larger and especially zoomed-in views. A folder containing 170 nominally 9 Mpix jpegs takes several minutes for all the thumbnails to be fully rendered (and their captions turned from red to black), and during that time PM is hogging almost all the CPU 'space' and is thus extremely slow to respond to attempts to carry on doing anything within the program during that process or indeed doing anything in any other program while I wait.

Then, when I use the zoom function for any image, once again the CPU churning resumes for something towards half a minute, so that I have to wait before I can move to the neighbouring photos.

I note that there is no parallel problem when I load such a folder (and indeed the same one) in the browser of XnView. There the browser thumbnails all render in a very few seconds, with no obstruction to my continuing to carry out actions within the program. Also, I have not had such a CPU-hogging from any other program (apart from the odd very rare situation where the whole system has become unstable - but such events are not really a feature of this system (so far!).

I'm using 32-bit Windows 7 Home Premium with all updates, with 2 Gig memory, and Intel(R) Core(TM)2 Duo CPU  E6750  @ 2.66GHz.

Is there any debug information I could get from PM to assist you in addressing this problem?

I can tell you from my testing and profiling that PM 4.6.6 is head-and-shoulders faster at scanning directories and rendering images than any previous version of Photo Mechanic.  That said, I'd expect that you are experiencing virtual memory paging.  2 GB of RAM on a Windows 7 system isn't very much RAM, and if you've got a number of applications running, and you've given PM any significant sized memory cache then you're soon going to be paging virtual memory pages which can cause significant slowdown.

How free memory is available before you launch PM?  How much memory have you set PM's Memory Cache to?

-Kirk

[Philip Goddard]

I was using the default memory cache value of 128 MB, but have just tried changing that to 400MB - which made no noticeable difference.

Just now when I tested, available memory before running PM was varying around 1307 MB, and with PM loaded and rendering the thumbnails for that folder of 170 photos, actually PM didn't take up very much memory, and that didn't appear to change significantly even after I'd upped the memory cache setting from 128 to 400 MB and saved that change (yes, and then exited and reloaded PM).

Clearly, if PM now has much bigger memory requirements than it used to have for carrying out the same task, that would be a most unwelcome drop in efficiency, even though with a lot more resources thrown at it, it could actually go faster than before.  Anyway, at the moment I've not yet seen any obvious evidence that memory is being a limiting factor on PM at all for this particular purpose - the system memory remaining more than half empty even when PM is working furiously at rendering all those thumbnails for the folder of 170 photos. It appears to be just the CPU that gets swamped by the task.

[Kirk Baker]

Philip,

I was using the default memory cache value of 128 MB, but have just tried changing that to 400MB - which made no noticeable difference.

Just now when I tested, available memory before running PM was varying around 1307 MB, and with PM loaded and rendering the thumbnails for that folder of 170 photos, actually PM didn't take up very much memory, and that didn't appear to change significantly even after I'd upped the memory cache setting from 128 to 400 MB and saved that change (yes, and then exited and reloaded PM).

Clearly, if PM now has much bigger memory requirements than it used to have for carrying out the same task, that would be a most unwelcome drop in efficiency, even though with a lot more resources thrown at it, it could actually go faster than before.  Anyway, at the moment I've not yet seen any obvious evidence that memory is being a limiting factor on PM at all for this particular purpose - the system memory remaining more than half empty even when PM is working furiously at rendering all those thumbnails for the folder of 170 photos. It appears to be just the CPU that gets swamped by the task.

Where are your photos stored?  Does the device that they're stored on have a fast transfer rate?
How are you sorting your photos?  By filename?  Capture Time?

-Kirk

[Philip Goddard]

The photos are stored on partition F on my internal hard disk (which has been their location all along). They are sorted by capture time. These cannot be real issues here, because there was no problem in that situation before v.4.6.5 of PM, and even now XnView doesn't have this trouble at all with the same photos in the same location, and also sorted by capture time.

[Kirk Baker]

Philip,

The photos are stored on partition F on my internal hard disk (which has been their location all along). They are sorted by capture time. These cannot be real issues here, because there was no problem in that situation before v.4.6.5 of PM, and even now XnView doesn't have this trouble at all with the same photos in the same location, and also sorted by capture time.

Just as a test, sort by Filename instead.  Let me know if that improves anything.

Thanks,

-Kirk

[Philip Goddard]

Just tried, and I see no obvious improvement. To make sure that I was working from scratch, in Preferences I set the default sort method to filename, then exited and reloaded the program, so that the sort method was being used immediately upon loading.

[Kirk Baker]

Philip,

Just tried, and I see no obvious improvement. To make sure that I was working from scratch, in Preferences I set the default sort method to filename, then exited and reloaded the program, so that the sort method was being used immediately upon loading.

OK, then I'm going to have to get you a build with logging in it.  I'll contact you later today with the link to the build.

-Kirk