I assume that you mean bytes used, and not some performance parameter, say % of free space. Is that correct?
If so, you can watch the file size of the TMP file, as you work. On the PC, that would be through Windows Explorer, but my guess is that the Mac has something very similar (maybe Finder?).
Note that the size will depend on several factors, starting with the amount of installed RAM, but also number and sizes of Open Images, and then the functions performed ON those Images. For instance, having 5 3000 x 4000 x 300 Images Open, will have less of an impact on the TMP file size, than if you then Merge those with HDR, or stitch them into a Pano.
I have never benchmarked the TMP file size, to see exactly which functions grow it the quickest, but think that I recall Noel Carboni posting on that topic. Maybe he'll tell me I am crazy, or link to his benchmarks/observations. Then, what I would do is take what you consider your "worst-case scenario," and test, with the Mac monitor watching that folder and the TMP file. Were I doing that test, I would probably construct worst-case, then double that, i.e. say you work with HDR at full camera rez, and do that with 5 exposures - try with 10, so that your figure will give you "wiggle room," should a larger project hit your machine.
There are probably several utilities, that can do the monitoring for you, and tuck away in a corner of your screen, but I do not know of any off hand.
Just watch the root folder of the scratch drive (or the TEMP folder if your scratch drive is your system volume). You'll see Photoshop create one or more files of the form Photoshop Temp121883162700 (the numbers differ) that house scratch data.
Configure a lot of History states and work on huge images or stitch a big panorama and watch Photoshop eat up hundreds gigabytes of scratch space.
What if it's disk "thrashing" and there are no temp files?
Or any other thing that does not create a file per se?
Aren't page swaps the basic indicator of "out of ram"?
Tho that shows up in the "memory pane" of the activity
monitor, not the "disk activity pane".
I also have iStat activity monitor, fwiw.
Thanks, I've wondered for a long itme about this.
The term "thrashing" generally describes when multiple programs read/write to different parts of the disk nearly simultaneously, meaning the thing has to seek its heads all over the place to get to the data.
If Photoshop is involved in that you should see the temporary scratch files - it does not read/write to the disk other than in files. Those files are, of course, deleted when Photoshop quits.
Though folks have traditionally advised dedicating different disks to the various major tasks (OS swap space, Photoshop scratch space, data files, OS files), the best solution to thrashing I've found is with new technology: SSDs, especially arrays of SSDs. There's virtually no seek time, so the concept of thrashing is pretty much non-existent.
Are you trying to solve a particular problem, or just trying to understand how things are working so as to be able to better tune your system?
FYI, I'm a PC expert; I could tell you a lot about what to watch in Windows, but I know almost nothing about OSX tools. The concepts apply, but the specifics are different.
Since the scratch disk seems always 95% unused, I wonder.
I also see page swaps. I guess I'd like to know what parameters
to watch and when to watch it to understand how valuable
500 GB of scratch disk is.
In your normal use of PS, what are you usually doing? That could well be a determining factor, as to the size of the Scratch Disk.
PS - Noel, thanks for dropping by.
plenty, just like the stress test above suggests
I just wanted to follow up... My information above is somewhat flawed. While it is accurate for Photoshop installations on Windows systems, I have just learned that apparently Adobe does something kind of funky with the Mac file system and unlinks the scratch files while they are in use.
Thus you will not actually see the files in use - you'll have to watch the disk free space indicator to see how much Photoshop is using.
Sorry for any confusion I may have caused.
I'm always confused, so that's ok.