Question about memory usage in PI XL

[MaryLouW]

Jim, I would suggest that, rather than load the entire meg image into PhotoImpact that you do a partial load. You can select whatever portion of the image you're working on. This would help solve a few problems in that it wouldn't take nearly as much memory.

If you have any third party plugins, you may want to uncheck the pointer to them because all of those loaded when you load PI. And last but not least, if you have an excessive amount of fonts, they too eat up memory as all of them are loaded when the program loads.

MaryLou

<font face="Verdana, Arial, Helvetica" size=2 color=navy>
MaryLou, RtD</font>
<hr>
<table border=0>

<tr><td align=left>
<a href=http://wwell.net>
http://www.pircnet.com/bb/buttons/ww-tutorials.gif</a></td>

<td><font face="Verdana, Arial, Helvetica" size=2 color=navy>
<a href=http://www.pircnet.com>PhotoImpact Resource Center (PIRC)</a>


AIM: MaryLouJW E-Mail: <a href=mailto:mlwhite@pircnet.com> mlwhite@pircnet.com</a></font></td></tr>
</table>

[jimojimo]

MaryLou,
Thank you. I will try those things--I had forgotten about the plug-ins, but I have a couple of those.

The problem most definitely returned after I reinstalled though. I'm convinced that the crux of the issue is Pixl's memory managment (or lack thereof). I 'solved' the problem from a practical sense--I bumped my Ram from 512 to 1 Gig. So the slowness is gone, but I can tell that pixl is not only using up the ENTIRE 1 gig--but it's going to the swapfile for another gig and then some. My pagefile usage gradually increments throughout a pixl session to over 1.3 gig. I watch it happen as I open/edit/close each image--up, up, up.

Now come on, ULead. Over Two full gigs of memory and the most I have open at 1 time is 3 images totalling 40-50 megs? And only 2 undo levels. Where is that memory going? It's leaking, that's my professional opinion. As a software developer I know how these things happen. And I know these leaks can be difficult for a programmer to track down, but reducing memory leaks is part of developing a bulletproof system. I'm not really complaining too much though--I am thoroughly impressed with the rest of Pixl, and for the money, I guess I shouldn't expect perfection.

I will try unloading some fonts and the plug-ins, but as I said, I threw hardware at it and solved the practical sense of the problem.
Thanks again,
--Jim

[jon spain]

From what I've been told elsewhere, the installed fonts don't consume much memory in 98SE onwards because small pointers alone are loaded (unlike 95). So this may not help but I'll be happy to be told I'm wrong if I am

Jon

[jimojimo]

jon,
It's Windows XP, sp1. I'm not sure about just the font pointers being loaded, at least not in pixl, because as you scroll through the font list for a text object the preveiw for each font pops up, and the fonts have to be at least partially--if not fully--loaded for that to happen.

But I really don't think it's fonts or even the fact that I'm not partially loading the image--although those things would certainly help. Pixl is eating up gobs of memory--way more than fonts or the images I'm loading. And it's not realeasing it--maybe it's the clipboard, maybe the 'undo' structures, I'm not sure what. But my swapfile goes way past a Gig, which should only be drawn upon when physical memory is exhausted--which is 1 Gig, and I'm dealing with images in the 5-30 meg range.

Maybe what I'm doing isn't that common, but I think it's normal. I'm not opening an image and editing with it for hours and then saving it. I'm doing mass-production--bringing in an 8x10 scanned image, cut/pasting it into 4 new 4x5 images. Then, on each of the 4, doing a rotate, maybe a brightness adjustment or filter, then save & close. I probably do 15 8x10 images in an hour (60 separate new images).

Before I added the second 512 stick of RAM, it would take about 30 min. before the swapfile and disk thrashing got to the point where I simply could not work at all--I'd have to close pixl and restart it, which drains the swapfile and I can work again. Now I can work much, much longer, but the swapfile still gets up there. I've masked--not solved--the problem with RAM, but I just don't think one should need a gig of memory to do the kind of work I'm doing with pixl.
--jsteph

[gidgit]

I duuno, I think it may have something to do with the specific system config... I mean I only have a very small Celeron 400, with only 256 megs ram and a puny 8 meg 64 bit v card, and am running Win98... to which, well... I mean it isn't gonna win me any grsfx races for sure,but yea... I am able to use PI just fine, and I have tried out XL and didn't have any bumps along the way... sure I can see the progress bar when applying fx. and of course I only have the undo level set to 50, and auto save is a must go from the git go, but yea... it even runs on my wife's machine... 266 Celeron (no L2), 192 megs ram, 16 meg 128 bit vcard...

so in short... I really dunno what to say, other than it works as PI always does, over here http://www.talkgraphics.com/images/smilies/smile.gif

hope you get this resolved http://www.talkgraphics.com/images/smilies/smile.gif

[MaryLouW]

Just had another thought - are you running the autosave feature? that really hogs up memory because it has to keep track of where you are and watch the clock so it can save according to the time you specified.

MaryLou

<font face="Verdana, Arial, Helvetica" size=2 color=navy>
MaryLou, RtD</font>
<hr>
<table border=0>

<tr><td align=left>
<a href=http://wwell.net>
http://www.pircnet.com/bb/buttons/ww-tutorials.gif</a></td>

<td><font face="Verdana, Arial, Helvetica" size=2 color=navy>
<a href=http://www.pircnet.com>PhotoImpact Resource Center (PIRC)</a>


AIM: MaryLouJW E-Mail: <a href=mailto:mlwhite@pircnet.com> mlwhite@pircnet.com</a></font></td></tr>
</table>

[jimojimo]

MaryLou,
Thanks, I had tried that before and it does help by just having autosave stay out of the way--since the default is 5 min, I'd often be waiting on an hourglass for the other disk thrashing, then when I thought I'd get the machine back--the autosave kicked in, so I had disabled it, but it's now reenabled.

gidget, Marylou,
Have either of you noticed anything when doing repetitive stuff like I described? A typical process cycle for me is (which is repeated every 2-3 minutes or less):

Open main Image--about 30 meg jpg, which is a scan of 4 photos that were arranged on the flatbed scanner;

Select single photo (1/4 of main image);
ctrl-C (copy selection);
ctrl-n (new image 'same as clipboard');
ctrl-V (paste to new);
Shift-M (merge);
Click the Transform button; Rotate (either 90 or 180);
Express-Fix--usually exposure and color cast;
Ctrl-s (save) save to jpg (100% quality);
epeat with next 3 selections;
Close original;
------
Open next scanned image and repeat cycle.

I'd have Task Manager's 'Performance' tab open, and after each main image I noticed the swapfile would grow by about 80-150 meg after each image. So after just a few images, the swapfile was near 1 gig.

Prior to adding more RAM, I would notice after maybe the 4rd or 5th main image, that when I'd go to make, say, the second selection, that the prior selection box would very, very, very slowly un-draw, and the new selection box would very slowly draw itself. This would take at least 20 seconds, sometimes nearly a minute! All the while the red disk light is full on, the disk just thrashing away. Closing pixl would start with a clear the swapfile, and I'd be ok for the next few images.

Now of course the slowness is gone, but the swapfile still grows huge, and I can see the selection boxes un-draw/redraw, but very fast, since it seems to be happening in memory, not the disk.

My guess is that one of those aforementioned operations is just not clearing itself out of memory, and it's staying in the swapfile (which is, as far as pixl is concerned, RAM). As I said, I develop software, and I'm well aware of the issue of 'memory leaks', and when developing an app such as pixl (any app, for that matter), extreme care and attention to detail must be taken to prevent these leaks, and I admit that it is not easy and leaks are possibly the most common 'bug' in programs--probably 99% of programs have these, but mostly the scope is small and the manifestation isn't serious and so they go unnoticed.

I've tried fiddling with registry settings that keep certain things in memory (Windows Exec files, for example) and I've had the swapfile on different drives, etc. but regardless of all that, I just don't think all that memory should be used for what I'm doing. I can see where it might need it *while it's doing those operations*, but once done and the image is closed, that memory should be released, and obviously it's not.

I'd be very interested if anyone has tried similar steps like that repetetively and noticed the same thing.
--Jim

[gidgit]

Hi ML... yea that auto save, though a nice option for some, really just gets in the way for others eh http://www.talkgraphics.com/images/smilies/smile.gif

Hi Jim... hmm, repetitive tasks... haha...

it's all repetitive tasks when using editors of any sort... Here's to tasks managers, and improved workflow, within all apps http://www.talkgraphics.com/images/smilies/biggrin.gif

While suggesting that I have not noticed such concerns with PIXL, as you have, it should also be noted that I did follow through with such testings as have you... hmmm

I would think that if anybody in the PI community knew of this type of bug, that somebody would have posted such already... ML here for instance, has a PI specific board, to which, should suaid bug been noticed by the members, and brought to attention, then I would think ML would know about it... really http://www.talkgraphics.com/images/smilies/smile.gif

so I really don't have an answer for you Jim, not as of yet anyways... we will look further http://www.talkgraphics.com/images/smilies/smile.gif

[jimojimo]

Well I tried it on another machine. I downloaded the trial version so I could test it on this machine. It's similarly configured, a P4 2.5 gig Dell with 512Meg ram.

I just created a new empty image 5000x6000 pixels--about the same size as the ones I was doing (8x10 inch at 600dpi)--then I hit print-screen and pasted that in until the image was full, and saved as jpeg/100%. About 30 meg or so.

Then I selected a quarter of the image, did new/same-as-cliboard, pasted, merged, flipped, did some edits, and saved. Did that 4 times, closed, reopened and did it again, and sure enough the swapfile was huge--only 800meg on this--but that was only the second go-round.

And the selection box was very slow to un-draw/re-draw, and there was alot of disk thrashing. If you all have done similar and things with similar sized images and things just snap along with no delays and disk-thrashing and big swapfiles, then I've got to be doing something wrong.

I have heard from ULead, and they are looking into it, so hopefully I'll know something soon.
--Jim

[gidgit]

Hi Jim... perhaps try out PI8, and let us know how it goes with v8 vs XL with your system... basically the same toolset, minus a few new wizards etc...