Management of Photoshop scratch/temp files

Photoshop
,
1

Can someone (preferably from Abode) confirm or deny the information that I am receiving from AI regarding the management of scratch memory.

The context is that I currently have a prototype Photoshop Plugin which, each time that it runs, reduces the free memory on disc by 1 GB or more each time. The memory is only released when I close Photoshop. I am fairly sure that this does not arise because of a code error on my part. I have thoroughly reviewed and revised my code and so has more than one AI tool.

The observed behaviour seems consistent with the advice that I am getting from ChatGTP. – “Users often see scratch/temp space not returned until a purge or Photoshop restart”.

I tried an experiment to see whether my memory loss was due to stored history by including a ‘purge all’ at the conclusion of processing. It had no effect. ChatGTP has advised me thus. –

“purge → All doesn’t work in UXP because Photoshop does not allow batchPlay-triggered Purge commands to clear the History store.

Inside UXP, the History system is protected when:

the plugin is still running, a modal execution block is active, or a panel callback has not fully returned to Photoshop.

Therefore, Photoshop silently limits the purge, even though the batchPlay call reports success.”

ChatGTP states that to purge history I must either create a duplicate document and close the original or implement purge using a menu command triggered after plugin closes.

Returning to my original issue of memory loss, ChatGTP advises me that

“Your plugin is not leaking memory.

What you are seeing is:

Photoshop creating temporary scratch files on C:

for duplicated documents, for intermediate layer bitmaps, for Undo states, for History snapshots, for Smart Object caching, for document preview tiles, for expensive filters (especially batchPlay operations inside )

They are not freed until:

the document closes, Photoshop completes its idle cleanup cycle,Photoshop is fully idle (no modal execution), and History is cleared,

Because your plugin does not purge history, Photoshop cannot reclaim many of these scratch blocks.

This perfectly matches your observations.”

ChatGTP also advises me that ,Purge “imageCaches” is “a legacy CEP/Scripting instruction. Photoshop’s internal code removed this instruction around PS 2022. Also, Photoshop does NOT guarantee that purge(“undo”) works”

“There is no purge operation in modern PS that clears image caches except:

close document, close duplicated working doc, write new history state (sometimes releases tiles)”

Can anyone please confirm the following advice from ChatGTP for the management of memory arising from scratch/temp files.

(I don’t really wish to rework my code until I am confident that it will be worthwhile.)

“Use a separate temporary document and never modify the user’s working document directly.

Workflow:

Duplicate original doc

Run entire plugin processing on the duplicate

Copy the final layer back

Close duplicate doc → frees ALL of its scratch and temp history

User’s original doc retains full undo history

This avoids:

large scratch buildup, history conflicts and user data loss

And it is the method used internally by several Adobe plugins.”

1 Like
2

Don’t trust ChatGTP in this topic.

Photoshop often allocates more memory than it needs. Once it has it it might not be willing to release it… but rather keep it allocated for future operations. Or at least some of it. If it allocates more than it needs it will ensure that it can be more performant in some intensive tasks because it does not need to spend time figuring out how to allocate more. Purge can help.

2 Likes
3

ChatGTP may or may not be trustworthy in this case, hence my question.

Clearly, Photoshop is unwilling to release memory, but there is no evidence that it keeps it allocated for future operations. It repeatedly increases the memory each time that I run the plugin which suggests that on a later run it is not using memory that that it had reserved on earlier runs.

Purge does not appear to have any effect for me. My experience aligns with that described by ChatGTP. I am pretty sure that it is correct on this specific issue but I would still like official confirmation from Adobe.

Please can someone from Adobe respond to my opening post.

4

@samgannaway Do you have any info on this experience?

5

What does the plugin do? The kind of operations done in Ps could help us determine the memory situation.

If you manually take the same steps, does the same memory allocation happen?

1 Like
6

Man, ChatGPT hallucinates methods and objects beyond its existence for UXP, as Jarda said, never trust CharGPT for this. Photoshop has indeed A LOT memory leak everywhere, that is being known for centuries. Something that Photoshop does a lot that drains the temp files is the .psb files, they are stored in temp directory and they consume the soul of your computer.

So my guess is that you are using a lot of SmartObjects maybe? Cuz if you are not storing things in RAM inside your plugin, this might be the memory issue.

If you share with us a little bit more about what your plugin does in terms of Photoshop instructions, we could come up with more solutions or better, find the “bug” if there’s one.

As I always say to my clients at support, the more you elaborate your problem the better we can help and find a solution faster for you.

1 Like
7

"What does the plugin do? The kind of operations done in Ps could help us determine the memory situation.

If you manually take the same steps, does the same memory allocation happen?"

The plugin is fairly complicated and includes some proprietary processing.

Before I started on UXP I did a ‘quasi’ prototype recorded as an ‘Action’. I thought the first step would be for me to run the Action and see if it similarly consumed memory. Unfortunately, that Action at present is not behaving. I get the message ‘The command “select” is not currently available.’ When I find the time I will explore this further.

8

I now have my ‘quasi protype’ Action running. (I had forgotten that the requirements for input images were far more restrictive for the protype Action than for the plugin.)

Once the Action was running, I used the ‘Copy as JavaScript’ facility to convert the Action into a JavaScript (.psjs) file.

I ran the JavaScript a number of times. The first time I ran the JavaScript the ‘available memory’ was reduced by 0.9 GB but on subsequent runs it was only reduced by a further 0.1 GB on each run. For 10 runs the total reduction in ‘available memory’ was 1.8 GB. A manual ‘Purge All’ reduced this deficit to 1.5 GB. Deleting the subject images had no effect., but closing Photoshop restored the ‘available memory’ to within 0.1 Gb of its starting value.

From the preceding, I have made a number of deductions

- Memory usage was not particularly concerning for these JavaScript runs

- ‘Purge All’ has limited effect in terms of memory release even when applied manually (let alone within UXP).

- Image deletion does not have any effect on memory.

- Photoshop releases all memory when it is closed.

I asked a number of questions regarding the AI advice that I had been given.

I was told that “Users often see scratch/temp space not returned until a purge or Photoshop restart”.

This is partly correct in that a Photoshop restart is normally required to fully restore memory. On the other hand, ‘Purge All’ has only a limited effect in terms of memory when performed manually and as far as I can tell ‘Purge All’ has no effect when performed within UXP.

I was told by an AI tool to

‘Use a separate temporary document and never modify the user’s working document directly’

Whilst this is good practice in general, I have concluded that it offers no advantage in terms of memory management. It would only be an advantage if closing the temporary document released some memory, but I have found that closing documents does not release memory.

The fact that this .psjs file runs with a low memory attrition, suggests that Photoshop JavaScript element of my plugin may be capable of running with only low memory attrition. Perhaps I should look again at the WASM element of my processing. That said, the memory reduction seems to be independent of the image size that I ask the WASM element to process (by implementing a resize before setting up the processing and a resize (back) afterwards.)

I have now answered the questions that I asked regarding AI advice. If I had undertaken that all of that advice, then I would have applied unnecessary changes to my plugin code without receiving any benefit. Because I have resolved that issue I will close this topic.

I have partly reduced the memory deficiency by updating my GPU drivers. More investigation is need which might cause me to raise further topics.

1 Like