The scratch sizes are coming out way too high in CS.
For example, on a fresh load of CS, get a new image, 7×5", 72dpi, 8bit RGB. This should generate a 531.6k image. CS creates the image and then shows scratch sizes as:
Scr: 570.8M/1.00G
570MB??? Where’s it getting this from? I see similar behavior when opening existing images. CS’ performance seems to bear out this issue, as if I have just a few images open, performance starts crawling.
On Photoshop 7.0.1, the same action gives me a scratch size as:
Scr: 37.1M/1.07G
Ok, that’s more like it. What’s with this? Same machine. Seems something is busted.
Could anyone at least try this out for themselves and report back if they see the same behavior? If you don’t know how to see the scratch sizes, click on the arrow on the left-hand side of the status bar, and select ‘Scratch Sizes’.
just tried this on my laptop and got the same results as you. It appears to be somewhat dependent on the physical RAM in the machine (I’ve got 768 on this one, with default memory settings in photoshop).
Anyone have any idea why the scratch disk usage is so much higher/image than PS7 was? Something still seems way out of whack.
I’m seeing the same sort of behaviour. 53MB file with 4 adjusment layers and 5 alpha channels in PSCS has 406/818. Same file in PS6 on same machine has 252/818. Flattened version of same file has 272/818 in CS and 135/817 in PS6.
I’ve also noticed some strange behaviour which I reported in the bug forum a few nights ago in saving files with adjustment layers. They come out twice the size on disk as they should. I resave them (save as with same filename and overwrite) and they come out at normal size. Chris Cox suggested I was using 16 bit files but this is not the case. Definitely a bug but not consistent.
I’m on default settings as I haven’t changed anything.
History states: 20 Cache Levels: 4
75% of RAM allocated to Photoshop (1051MB of 1401 free)
I actually tried working on a real doc with 8 tonight and my scratch disk usage is up to about 2.5GB after working on a few small documents.
It seems that CS is allocating *way* more per file than it used to be in 7 and earlier. As I recall from reading long ago, Pshop allocates several times the image size in scratch space. Now its more like 100x.
Here’s my system info dump as well:
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: 2266 MHz Built-in memory: 1536 MB Free memory: 990 MB Memory available to Photoshop: 1402 MB Memory used by Photoshop: 75 % Image cache levels: 4 Use image cache for histograms: No Application folder: C:\Program Files\Adobe\Photoshop CS\ Temporary file path: c:\Temp\ Photoshop scratch has async I/O enabled Scratch volume(s): C:\, 37.3G, 26.5G free D:\, 111.8G, 58.9G free S:\, 9.77G, 6.65G free
Well, my first message in this thread gave you specifics about my test case:
— For example, on a fresh load of CS, get a new image, 7×5", 72dpi, 8bit RGB. This should generate a 531.6k image. CS creates the image and then shows scratch sizes as:
Scr: 570.8M/1.00G
On Photoshop 7.0.1, the same action gives me a scratch size as:
Scr: 37.1M/1.07G —
That will reproduce the problem.
In a real case, I’ve right now got 2.3GB/1.00G of scratch size, with the following images (sizes are size on disk):
1) You’re looking at the scratch sizes NOT the image size or image memory.
2) It looks like you may have a bunch of presets loaded and taking up scratch space.
3) Yes, CS will have larger scratch sizes (the 500M vs. 37M) because the tile sizes increased and there are additional resources allocated from scratch space.
Is it normal for the scratch size (monitored by checking in windows explorer) not to reduce whilst any images are open in PSCS? I had a 97MB image open with 4 layers, total size ~400MB rotated it a few times, opened and closed a few smaller images ~3MB. The size of the scratch file (as reported by windows) reached about 3.5GB. After doing a Purge>All the size of the scratch file did not reduce, only when I closed all the open images did the scratch file returned to 570MB. The last image I closed was the large one.
Will the scratch file continuously grow during a PS session or does it reach a limit once the 20 saved history steps have been reached? I am probably wrong but it thought that the scratch file size reduced in PS7 when you did a Purge>All.
Also what are the presets you refer to in your post?
Tried opening two large files ~400MB and one 30MB file doing a few image rotations scratch file size just over 4GB. After closing the large files and purging all the scratch file reduces but not by much. It looks like scratch file size does not tend to reduce during a Photoshop session.
Chris, Thanks for the info the file sizes were image size = 90MB size in memory ~ 400MB. I guess my copy of PSCS is working as expected. Looks like I made the right choice of allocating an 8GB partition as the scratch drive, I was beginning to think I had been over generous with the scratch disk when I was using earlier versions of PS.
I can stop worrying about how I had set it up and start getting to grips with all the new stuff plenty to go at as also have all the rest of the Creative Suite Premium to learn (all of which is new to me) An early Christmas present to myself but I think it will be Christmas 2004 before I have learnt it all 🙂
My initial test case still hasn’t been explained. Chris…can you call it correct or incorrect CS behavior? Should a 530k file really allocate a 500MB scratch space (even though PS 7.0.1 only allocates 37MB for the same file)???
I run a whole lab dependent on this app and I need to get this solved. I can reproduce this on every machine I try, whether Mac or PC. The scratch space usage does seem to vary depending on the amount of scratch allocated, but in every case its way more than 7.0.1. was (like 60x).
Hmm, ok. I’m using exactly the stock setup as installed by Adobe … nothing modified with this installation. Does the stock set of presets add up to 500MB for a 530k file?
I checked a layered 200Mb file I’ve been working on. Opened in PS6, the reported scratch size is 807.5Mb/577.8Mb. Opened in CS, the same file has a reported scratch size of 1.44G/577.8Mb. Default presets for each version.
Seems extravagant to me. Not only is the startup scratch bloated for a new file, the bloat seems to grow as one works. Is this expected behavior or a bug?
I’m not sure what I’m supposed to be seeing. Sorry to be obtuse about this, but the scratch size for a new file (blank document) on start-up is the same regardless of the pixel dimensions (343.3Mb).
Ho – ok, that means that the default scratch size is close to 343 Meg, which is about what I’d expect to see on a machine with 512 Meg to 1 Gig of RAM. (closer to 550Meg on a machine with over 1 Gig of RAM).
BTW – part of that added scratch size at launch is due to buffers we need to composite images, and adding the nested layer sets greatly increased the number of buffers we need (and have to pre-allocate to prevent out of memory errors).
Thanks for the info about the tiles! Still I don’t see the relation between tile size and presets? does Ps break all it s data loaded on HD using the tile size as a reference?
5to make it clear, when I talk about tile size, I mean the ones that you can have information when you ALT+click the infobar, where you can see the document size…
It’s rather convenient that the New file dialog states what the resultimg image file size will be. In the case of the default parameters it does indeed state 531.6 K. The scratch size reported showed up as 79.1 M/168.4M on my PC which has 384MB of RAM. Then I looked at the Memory & Image Cache setting under Preferences, which I had at 50%. I upped this to 80%, then exited and restarted PS.
On generating the same 531.6 K file, the scratch size became 148.0M/269.6M. So, the reported scratch file size varies with the amount of RAM you’re allocating to PS. I have no idea why this would be, and in any event, it seems like a large allocation for a scratch file. Lastly, one would think the scratch file would need to be larger the LESS memory allocated to PS.
Pierre – each sampled brush or pattern goes into an image array. The minimum size of the image array is the size of a tile. So if you increase the size of the tiles, you increase the disk space taken up by all the sampled brushes and patterns.
Allen – the scratch size includes a LOT more than just your image size. That’s why it’s called the scratch size, and not the image size.
And the scratch has to (potentially) hold everything that is in memory – so the scratch does increase with RAM size.
Chris I’m experiencing the same phenomenon on my machine. I can open up a 2meg file and my scratch use goes to 600megs upon opening with a Gig and a half of ram. Is CS basically a memory hog, or is there a way to get rid of some of the presets, without effecting the workflow. Thanks Rob Jaffe
Hello Chris I read every message starting from the beginning before I posted. I couldn’t figure out if you addressed a practical way of reducing the scratch usage by deleting presets, or is large memory use just inherent to CS. Thank you Rob Jaffe
Rob – I explained why the scratch usage is larger, and implied that you can reduce it by reducing the number of sampled brushes and patterns. But if you have a lot of RAM, then the scratch usage WILL be greater in CS.
Ok, Chris, I get you , now… 1)By "sampled" presets, I guess that you mean the ones that are actually displayed in each preset window, or those listed in the drop-down list? (more presets…)
2)For someone in a dire need of more ram, would creating an empty preset be a good option, or should one clear the "more preset" list, and load them elsewhere? Thanks by advance…
Pierre – no, sampled means that you sampled them from an image: "define brush", "define pattern".
The presets don’t affect RAM, just scratch space overall.
You would have to load a lot of presets to make a noticable impact on RAM usage. And in that case I’d remove all but one of the preset type to free memory. (if you remove all of them, then we reload the defaults)