I have been given to understand that these RAM monitoring and "cleaning" facilities don’t do anything useful that Windows doesn’t. Programs free up memory when something else needs it but not before; hence the apparent memory leaks.
Cheers – John
Short term, some report that RAM Idle LE helps:
<
http://www.tweaknow.com/ramidleLE.html>
Appropriate REAL fixes:
1) Full BETA testing instead of using the M$ model of large scale beta’ing by using Version 1.0 Gold as the final beta. (of course that means more leaks of coming feature sets and more Betas being distributed in violation of the license around the net – neither help the bottom line)
2) A rebuild of ADOBE’s proprietary memory code, or a shift to an OS driven one – in either case they need memory management code that plays better with contemporary OSes and is better prepared for the incipient 64 bit platforms. (Of course, M$ style feature bloat seems to be a bigger priority).
A bunch of us have seen this problem already, there was an earlier thread on it.
Until there’s a patch, the only solution is closing and reopening Photoshop.. Of course, if you’ve got a lot of plugins, that’s a real MIPS and time waster.
Keith
Paxton,
Photoshop does not release memory when an image is closed. This saves having to re-allocate it when the next image is opened. What you are seeing is perfectly normal and the application is working as designed.
Photoshop does not release memory when an image is closed. This saves having to re-allocate it when the next image is opened. What you are seeing is perfectly normal and the application is working as designed.
So you are saying that this is not a bug, but a feature?
Reallocating memory is a fast hardware/software process that is being avoided to make the user experience painfully slow and unproductive? Unproductive to the point of closing and reopening the ^&%$%#$#@! program after every few images? That make zero sense to me. 1-1/2 Gb of RAM should be enough resources to make any well coded program fly!
Paxton,
Unproductive to the point of closing and reopening the ^&%$%#$#@! program
after every few images?<<
You should NOT need tp close down Photoshop after every few images! The same memory is re-allocated to the new images you open. If Photoshop is slowing down you have another problem, and one which has been addressed here in several current topics. Chances are you have your Photoshop memory allocation set too high. Try turning it down to 50%
Ummm.. If you go back to those threads, even when memory allocation was reduced AND background thumbnail creation was turned off, some still report the exact same problem..
Here’s a hint Len… MORE BETA TESTING… I really dislike being a guinea pig for the overglorified script kiddies some like to call "Software Engineers.." Get it right BEFORE you ship..
Otherwise we have every right to:
1) Complain
2) Metaphorically, pee on the shoes of those who persist in refusing to completely overhaul (as a number of columnists and authors have pointed out) this obsolete and idiotic proprietary memory management architecture…
You seem to miss the fact that, as users, we actually PAY for this product (as an aside we get insulted and treated like potential criminals by activation for that price too). Nothing irks me more from Adobe than it’s consistent refusal to overhaul Photoshop’s memory management — or even to ever admit there’s any problem with it.
Frankly, as users we don’t give a rat’s behind how hard programmers have worked over the years to create and update the program’s memory management. It either works perfectly or it doesn’t.. There are no other options. This isn’t freeware of shareware, it’s expensive commercial software, and for what users pay for it they should get a fully vetted Gold version with the first release, not in some later "version X.01"..
However, nothing amuses me more than how quickly and with such gusto Adobe staff are ready to jump into the fray whenever the memory management issue comes up. It’s so laughably "Pavlovian"…
Ding Ding…
Woof Woof!
Keith
You should NOT need tp close down Photoshop after every few images! The same memory is re-allocated to the new images you open. If Photoshop is slowing down you have another problem, and one which has been addressed here in several current topics.
Let me reiterate. I start a session with 1036 MB of free RAM and work until it drops to 344 Mb of free RAM. I close the image and then load another. The 2nd image starts with 340 Mb of free RAM, not the 1036 Mb as when I first started CS…. If I continue the free RAM drops into the low 200’s and then work is really sooooo ssssllloooowwww…. I can’t tell if anything is really working except that its starting to thrash the hard drive in order to function at all… Nothing would appear to be "Reallocated" as you suggest….
Chances are you have your Photoshop memory allocation set too high. Try turning it down to 50%
OK, it is set to 50%
Here’s my settings:
Adobe Photoshop Version: 8.0 (8.0×118)
Operating System: Windows XP
Version: 5.1 Service Pack 1
System architecture: Intel CPU Family:15, Model:2, Stepping:4 with MMX, SSE Integer, SSE FP, SSE2, HyperThreading
Processor speed: 2219 MHz
Built-in memory: 1504 MB
Free memory: 949 MB
Memory available to Photoshop: 1373 MB
Memory used by Photoshop: 50 %
Image cache levels: 4
Use image cache for histograms: No
Serial number: xxxxxxxxxxxxxxxxxxxxxxx
Application folder: C:\Program Files\Adobe\Photoshop CS\ Temporary file path: C:\DOCUME~1\Zane\LOCALS~1\Temp\
Photoshop scratch has async I/O enabled
Scratch volume(s):
D:\, 98.2G, 3.36G free
It looks like a problem on the Mac side as well:
"PS CS and serious memory problems under OS X (Panther)" <
http://tinyurl.com/ywxjo>
Keith
Paxton,
There is no memory leak. What you see happening is what should be happening. There will be no fix because this aspect of Photoshop isn’t broken.
from your config list
Scratch volume(s): D:\, 98.2G, 3.36G free
Your disk is almost full and this can often result in a significant drop in performance (not just Photoshop) 20% free space is usually as tight as you want to go. Photoshop ALWAYS uses the scratchdisk. Your disk noises and slow down are more likely related to the nearly full disk.
I agree w/Ian.
In addition, you’ve mistaken some of your readings:
I start a session with 1036 MB of free RAM and work until it drops to 344 Mb of free RAM.
So far so good.
I close the image and then load another. The 2nd image starts with 340 Mb of free RAM,
NO! You’re simply using more of the scratch space you’ve allocated. PS isn’t releasing the memory in between images, it isn’t lost. It’s there for use by PS on your second image.
When you finally allocate up to your alloted scratch space (in prefrences> memory usage) you start swapping. Because you have so little free space on your drive you’re swapping rather quickly. Either get another hard drive, move the scratch file to a drive with more space or reduce your ps memory allocation even more.
Ian said:
There is no memory leak.
For once Ian, I’m going to have to say you are either obfuscating the truth or uninformed..
Scott Byer said in the Adobe Forums at <
http://tinyurl.com/2ja3a> :
Scott Byer – 12:22pm Feb 5, 2004 Pacific (#11 of 12)
Yes, there might be a problem, and we’re still trying to collect enough information to reproduce the issue and to figure out exactly what’s going on.
Apparently Ian, You know EVERYTHING that’s going on in Photoshop CS and can guarantee there is NO memory leak in PS CS… What tripe. If/when a patch fixes this "problem" I assume you’ll still deny there ever WAS a problem?
as for you David, just this past Friday, you even posted the following on the Adobe Forums at <
http://tinyurl.com/27gb8>:
If you’ve read any of the threads on this issue you’d know that they suspect something is funky somewhere but they’re having a hard time pinning it down. They need to eliminate problems that are local to specific installations in order to focus on things that might be real issues.
Since Ian said there is "NO memory leak" it would seem your other post disagrees, not "agrees" with him. If what you mean is the "memory leak" is probably not the issue in this case, that is a different issue.
Add in telling users to turn off hyperthreading in the BIOS to deal with tool crashes in PS CS and you have clear evidence of a real issue with the way PS CS is doing its memory management. The application should work w/in the OS and on generic hardware without having to disable features that give increased performance like HyperThreading. However you want to spin it, there is a documented memory/multithreading BUG in PS CS..
Recommendations:
1) If you intend to dissemble, don’t leave a trail of comments that contradict your current position.
2) When trying to spin a bug issue positively, it’s best if Adobe staff, consultants, contractors, and/or "experts" don’t publicly contradict each other on the existence of said bug (obviously, though, the random sycophants that are out there are beyond your control/jurisdiction). You’ll be called on that every time.
Just my 2 cents.
Keith
Paxton,
Scratch volume(s):
D:\, 98.2G, 3.36G free<<
Not enough free space! And the reasons for your slow-downs.
Ian also said:
from your config list
Scratch volume(s): D:\, 98.2G, 3.36G free
Your disk is almost full and this can often result in a significant drop in performance (not just Photoshop) 20% free space is usually as tight as you want to go. Photoshop ALWAYS uses the scratchdisk. Your disk noises and slow down are more likely related to the nearly full disk.
On that count, in this case, I agree completely with Ian and David.. AND I MISSED that point totally in your data, I’ll give Ian due credit for honing in on it right away.
YOUR problem, in this case, is MUCH more likely wholly a result of the scratch disk configuration. Scratch disks need to have a bare minimum of 20% free AND they need to be kept scrupulously defragged to allow for contiguous file reads/writes. You’ve got only about 4% free space on that D drive.. Even with a top-notch defragging utility you would have a nightmare keeping that small amount of open space contiguous and usable. You need to allocate more space on another partition or drive as your scratch disk.
Keith
Povimage,
Well, I hope you aren’t classing myself as "Adobe Staff". I am a User, just like you, and a VOLUNTEER Host here. We don’t get paid by Adobe, never have, and I very much doubt ever will.
Now the engineers WILL be vocal in refuting information that they know to be totally incorrect, and I whole-heartedly applaud them for doing so. The sort of mis-information such as ‘it has a memory leak’ does no-one any good, and should be stamped upon as should all mis-information.
For once Ian, I’m going to have to say you are either obfuscating the
truth or uninformed..<<
More mis-information…..
Scott said on Feb 5th.:
"Yes, there might be a problem, and we’re still trying to collect enough information to reproduce the issue and to figure out exactly what’s going on. "
He did NOT say anthing about memory leaks. In fact, since that date they have identified that SOME Win2k systems running with FAT32 drives are experiencing slow-downs. That is a disk access problem and NOT a memory leak, for goodness sake.
It would be sensible of you if you stopped drawing the conclusions you wish to use to back-up your own arguments and instead concentrated on what those that know a lot more about Photoshop than either you or me are telling you.
no one here (at least not me!) is defending adobe, keith. get out of lawyer mode. i have no reason to defend adobe. i’ve said in the past there seems to be an issue with some systems and 2 gig of ddr ram (possibly steve’s issue in the thread you linked above) and an issue with multiprocessors using tools and possibly an issue with win2k slowdowns under certain conditions. that’s what’s been sussed out so far. you’ve taken quotes out of context from threads about different problems and said they support the fact there is a memory leak. either you’re misinformed about what a memory leak is or your intent is to slur people who are genuinely trying to help. please don’t take yourself so seriously to think you can never be wrong or mistaken, or that every time someone points out a mistake in your suppositions it’s a personal attack.
Just my 2 cents.
most cases i’ve seen before you 2 cents have been valuable. in this case, it seems somone slipped you a couple of slugs. if you want to refute what i have to say, fine, no one wants to get to the truth about the technology more than me, but don’t call me an apologist. I don’t work for adobe and it’s in my best interest to find and disclose every bug i can find so I can have a better product for my hobby. as a developer at ANOTHER company, i know the sw development and debugging process inside out. when i ask questions or refute something it’s not in an effor to obfuscate, but to get at the root cause so that a solution by the ps developers can be found. and get your facts straight before you post. maybe have a cup of coffee before that first post of the day. 🙂
I have been reading this with great interest. Some clarification is requested:
When I close an image that has used "X" amount of scratch, that value continues in scratch, even though I have closed the file? In otherwords, if I were to check the scratch disk while PS is running and the file closed, I would find that data still present? I can try this for sure. If so, I could free the volume by deleting that file.
If I have a separate volume (I do) for scratch, there is no need to defrag, as there is nothing in the file. So, I don’t understand the instructions to keep scratch defragged.
I have in the past, found a file lurking in the scratch volume after shutting down and rebooting. An anomaly for sure, but I have seen it at least twice in my 3 or so years working with PS.
An anomaly for sure, but I have seen it at least twice in my 3 or so years working with PS.
When you open Photoshop a "temporary file" is created on the drive that you designated as the scratchdisk. Usually when Photoshop is closed it will clear this temporary file, but occasionally it doesn’t (usually after a forced quit or application crash). The temporary file IS your scratch file and its size should correspond closely to the left hand value of the pair labeled "scr" in the popup menu on the bottom left of the image window.
Edit:-
The temporary file is only visible if you have configured Windows to display hidden files and folders.
So, the memory pattern as described in this thread is normal and expected.
Keith,
It’s pretty clear you’re not quite understanding all the reasons Photoshop does it’s own virtual memory management. Even when everything moves to 64-bit, it will still be advantageous for Photoshop to manage it’s own memory. There are improvements that can be made to the scheme, and we’ll be making them. But nobody would but up with the reduced capability and performance going with a pure OS scheme would entail.
-Scott
Thanks, Ian. Windows is configured as you describe.
Scott said "Even when everything
moves to 64-bit"
I can’t wait for that!!!
Pierre,
I can’t wait for that!!!
It’s not a case of "can’t" – you have no choice 😉
I’m wondering when it will be a good time to get a 64 bit processor… and if the winXP 64 is stable enough, if you see what I mean…
A very interesting conversation and it looks like it has revealed some sore points as well.
I will try cleaning up my hard drive where the scratch disk is located in the near future and see if that makes a difference.
In spite of all the conversation, it still doesn’t make sense to me why the resulting performance deteriorates within 20-45 minutes if the memory is being managed so well by CS…. It performs nicely at the beginning of a session then gets worse, and worse, thats the facts.
Paxton–
It slows down because you are filling up your scratch disk space and Photoshop is literally out hunting for more.–I have my scratch disk set to an empty 60 gig partition that I defrag weekly! Nothing else is stored there–it’s just free space for Photoshop to do it’s thing with…it works like a dream!I also have a second 60 gig partition that I occasionally store stuff to, but is pretty much empty as my second scratch disk.
It sounds like you could really use a second drive and hard drives are cheap!cheap!cheap! Try investing in a large drive and then running Pshop with as large of a partition as you can afford to give it. You will not be disappointed!
In otherwords, if I were to check the scratch disk while PS is running and the file closed, I would find that data still present?
yes. it’s still allocated, but not "in use"… it’s like poking into what’s behind a null pointer. may be something fun… may be something not. it’s ready to be used by (only) photoshop, but whatever’s there has no meaning until it’s addressed again by another ps request.
2 Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.
(The Ten Commandments for C Programmers (Annotated Edition) <
http://www.lysator.liu.se/c/ten-commandments.html>)
I don’t understand: Defragging an empty volume..?? Nothing to defrag. Defrag won’t go there.
I checked my system, and, after running several files, all newly acquired, I exited PSCS and checked the Scratch partition. A file resided there, from PS, and it’s size was less than 10% of the dedicated volume. Given that scratch exceeded 1G on at least one of those files, it seems to me that PS is cleaning up after itself as it moves to new files.
Just my 2 cents worth.
David said:
said they support the fact there is a memory leak. either you’re misinformed about what a memory leak is or your intent is to slur people who are genuinely trying to help. please don’t take yourself so seriously to think you can never be wrong or mistaken, or that every time someone points out a mistake in your suppositions it’s a personal attack.
I have no problem with Ian’s analysis of this particular situation, I just felt it was a leap to hear him pronounce that there was no memory leak.
As an aside, I wasn’t taking Ian’s commentary personally, it’s just kinda difficult to remain wholly objective, or all "warm and fuzzzy" about Adobe, when I have Chris Cox calling me a "troll," on another thread dealing with some of these issues, for bringing these issues and quotes up.
Keith
Len,
I know quite well you are a volunteer.. And I know the work it involves (I moderate 5000+ users myself).. I have no axe to grind against you or anyone here..
Ok, I NOW have one to grind against Chris Cox, but he opened that can of worms by calling me a troll AND AFAIK, he does work for Adobe.
Suggestion: NEVER send Cox to do anything involving difficult contractual negotiations.
Keith
Some readers may recognise me from a similar long running thread a few weeks ago, when I was reporting "CS using HUGE amounts of memory".
I have to say I learned a lot about PS, its memory management and scratch disk use from the ensuing discussions. I think that what readers need to consider is that the scratch file is a combination of memory and hard disk space added together (if I understand correctly), and that the way those scratch file numbers work is actually correct, even though it looks absolutely crazy, and it appears that the machine slows down when certain memory/scratch situations have arisen (ie running out of scratch HD space).
It still frightens me when I look and see that the scratch size is up to 2+GB!!!
What has made a really big difference to my setup is adding a second HDD, and dedicating a 60GB partition to PS as the main scratch disk. This has transformed CS into being almost as fast as PS7! In my case I had over 70GB free on my C: drive, but still a second dedicated scratch disk has made a big difference.
Hope that helps.
Brian.
No wonder Chris is frustrated!
It says right at load up you should have Photoshop’s primary scratch disk set to a separate volume/or secondary hard drive and people keep ignoring it or think that they are smarter than the engineers that wrote the program. I have had a secondary setup since Pshop 6, it has always worked flawlessly and as drives keep getting cheaper ($99.00 for a Western Digital 120G/8 cache last week in the paper) I plan on upgrading drives to give Photoshop the space it needs.
You can’t expect top performance out of a Porshe if you only gave it one block to work with now would you!
I’ve never worked at any company where they’d buy second hard disks for every artist, or partition the ones they already have, just to keep PS happy when every other app in the Known Universe runs just fine on a single HD.
Besides which, as you said yourself, that suggested scratch disk configuration and related warning dialogue have always been there (at least since v5, not sure about previous versions), so a complaint based on a like-for-like comparison between CS and earlier versions is still valid.
Mqybe since CS uses bigger memory blocks, is it more affected by a fragmented disk than 7 was…
All I know is when I added the second hard drive and kept it clean and defragmented (the entire drive, being that I store some of my temporary client files to the second partion before burning these files to CD) is that all of my blue screens of death, not enough ram to perform this operation, and illegal operations suddenly cleared up and have not returned!
I plan on upgrading this hard drive to give photoshop more room to roam (120 gigs of clear scratch space). I work on 300mb and up files all the time and with the current configuration (60G clear/60 second partition with some temporarily stored files) I have not had problems, but I feel that by giving Pshop a 120G playground that I increase my performance and the reliability of my system. It’s a small investment for increased productivity and system stability! If your company can’t see that they are extremely short sighted!
omigod! I am going to need a HUGE drive only for scratch reasons? <sigh> I’m never gonna have enough system to run PSCS. 60GB of scratch space??? yikes.
I had not been to this site, prior to installing CS, because I did not need to. Everything always worked well with version 3.0 through 7.0.1.
My question is this. Has every new version created this much discussion? If not, then I would have to ask why CS has generated such a large volume of response. If this release has generated a lot more discussion, then there must be something wrong.
I do not know what it could be and I would not want to speculate on a cause. I do know, however, that CS seems to start HD swapping much faster, than previous versions, and it gets really slow at that point. I do have a separate drive, with 160GB free, for the scratch disc and 2GB of RAM. I have looked for a "sweet spot" on the memory slider, which improved things, but swapping still occurs sooner than other versions. I am referring to images in 8bit mode.
Dennis
But the problem is the more complex the program gets, the more complexity you are offered as a user, and you have to have a box that will handle that complexity. You guys don’t remember the old days before layers, rubylith, etc. when we absolutely could not do some of the things that we can do in Photoshop today.
Unfortunately,there is a price to be paid for complexity and that price is an increase in hardware to handle the system. And I would pay anything! absolutely anything to have the complexity and ability to manipulate images that I have in Photoshop CS.
Trust me, if you had spent 2 days and 100 of feet of rubylith (not to mention the band-aids) to cut masks that today we can do in a few minutes inside of Photoshop you wouldn’t be griping! You’d be lined up at Circut City buying the biggest fastest box you could afford.
Has every new version created this much discussion?
Sometimes more.
Bob
As I dont have Photoshop CS I have not read ANY of the previous posts on Photoshop CS etc… so take it into account when I answer with the following;
The apparant memory loss phenomenom; Operating systems (Most) give memory to applications when they request memory and it is available. When applications finish with the memory they do NOT give it back to the Operating System to re-use, well technically they DO give it back but the operating system does not add it too its Main Free Memory space, i.e. It is re-used by the same application when it is asked for.
The other factor that remains unanswered is the slowdown also; I cant say by actually using P-CS, It might be unique problem on your system etc. It should not usually be a side effect of the explnation mentioned in the previous paragraph.
….Thus the pattern for the memory tests in the topic problem;
Robert, from what you say, I guess that CS is no different from other releases.
Christine, I totally agree that the system has to keep up with new software and it’s complexity. For that reason, I update my systems mother board/processor every 2 years. In between there are usually upgrades to hard drives, cd/dvd recorders and RAM. The system I use now is pretty much up to date. Not the most fast (P4 1.8GHz, ATA 133 7200RPM drives) but not a slouch either.
Dennis
Robert, from what you say, I guess that CS is no different from other releases.
For me (heavy emphasis on FOR ME), CS is different from the other new versions in that it’s the first one that’s ever caused performance problems, compared to earlier versions on the same machine.
I would hasten to add that I feel like Adobe is trying to reproduce the problems that I’m seeing, and I’m sure that if they are able to do that they’ll be able to fix it.
I had the same slowing down of PS7, so I don’t find CS is any different in that respect. And my slowing down is NOT due to lack of memory (2GB between 50-80% allocated) or scratch file space (separate hard disk, separate scratch file partition of 10GB with Recycle bin and system restore turned off on that partition) since PS is set to use two other hard disks with about 100GB free space if for any reason the main partition does fill up.
I’ve always found it is better to close PS after working on an image or two, before starting another. It does then work faster.
An much more annoying memory problem that I have just encountered on CS is with the liquefy filter, as I have just described on another post. With a 100MB file it keeps giving up and showing ‘memory problem’ dialogs. No problem with small files. Yet as I said above there is over 100GB of empty defragged scratch space for it to use. Maybe liquefy only uses RAM – but I would have thought that 1GB or more for a 100MB file ought to be enough.
Bob Frost.
Some plug-ins aren’t the best citizens when allocating memory (yes, including our own, grrr) and try to allocate a single chunk big enough for the entire image. That means that you’d have to turn down Photoshop’s memory percentage even further in order to have the filter work on a larger image.
-Scott
Thanks Scott,
So, if I am understanding you, plugins need more of the Windows allocation of memory, rather than the PS allocation of memory. I knew my NeatImage plugin needed that, since it won’t run above 50% PS memory allocation, but I hadn’t appreciated that PS’s own filters worked outside the PS memory allocation – if that is what they do. I’d always assumed that providing you left enough memory for Windows to run, the more you gave PS the better.
So, am I right – that all plugins run in the Windows allocation of memory?
Bob Frost.
Have you installed Microsoft Fix Q815411? I found that a couple of programs of mine which use a large amount of memory ran faster following the install of this patch.
Also, in the arcane world of OS virtual storage management, when a program requests space it does not get it, it only thinks that it got it. The OS only allocates the memory space’s page tables to define them to the memory space.
Only when the program writes to the allocated memory block is the virtual page mapped to a real location in memory, and the real memory page is also written to the page file. If the program hasn’t used the real memory in a while, then the real location is deallocated (it doesn’t need to be written to the page file because that was done when any data changed).
So when Photoshop requests a large amount of memory and doesn’t use it, it has little effect on real memory.
I don’t know the internal workings of Windows memory management, but I have noticed that it is terrible anytime I/O is required. So even though we think we may have enough memory, the inner workings of Windows obscure the reality.
One test is to start Windows without a page file allocated. Observe the behaviour of Photoshop, then try it again with a page file allocated. Note that one needs quite a bit of memory (RAM) to perform this test.
John
Have you installed Microsoft Fix Q815411? I found that a couple of
programs of mine which use a large amount of memory ran faster following the install of this patch.
John is that a 2K or an XP patch? If it’s 2K could you let me have the url? have tried searching the MS site but it keeps saying not found….
Thanks…
Cheers…
JJ
John,
Microsoft have changed the title of this problem/fix to ‘Heap Algorithm update for Atypically large Heap requests’ which they say is found with only one noncommercial program, and do not advise fixing it unless you are running this particular program which they do not name!
Apart from that, thanks for the info. I’ll clearly have to do more reading on the workings of memory management.
Bob Frost.
Here is the description of the problem, which is with Windows XP:
<
http://support.microsoft.com/default.aspx?scid=kb;[LN];Q815411>
I found the link by searching on the id, Q815411, on this page:
<
http://support.microsoft.com>
They did change the description. The original described that the fix was for programs that requested large amounts of memory and improved the performance of the memory manager for those types of programs.
Here is the fix description:
Windows XP
Date Time Version Size File name
———————————————————— — 28-Feb-2003 19:05 5.1.2600.1177 654,336 Ntdll.dll
There is also a comment to wait for the next fixpack which should include the update. Interesting that MS would include an update which purportedly fixes only one program.
John
So, am I right – that all plugins run in the Windows allocation of memory?
Some plug-ins, not all. We’ve been fixing them as we see which ones are more important to our users and as we have time to get to them. A number of key plug-ins (e.g., Gaussian Blur, Unsharp Mask) are well-behaved and allocate memory efficiently, so you don’t have to worry about those.
For the poorly behaved plug-ins, how much they try and allocate from standard memory can often depend on image size, so the large the image, the lower they will force you to dial the memory percentage before they will work.
If there are particular plug-ins which are causing more grief to you because of this than others, I’d be interesting in knowing which ones.
-Scott
