SEARCH
diglloydTools™
Update on Photoshop CS5 DisallowFlateCompressedPSD.plugin
I’ve had readers write to confirm my findings (which I’ve proved resoundingly on two Mac Pros and one MacBook Pro). Not that I feel I need confirmation— a speed gain is a true positive— saving faster cannot be a mistake.
Update: see my follow-up notes.
NOTE: the DisallowFlateCompressedPSD has no effect on 8-bit images (confirmed by Adobe) only 16-bit images.
To be clear, don’t expect gains on small files on on systems that are not configured with plenty of memory and a fast volume (drive); I’m testing files in the 1GB on up range.
More than a few readers have written. Here’s one today:
We updated to 12.0.4. Saves w/plug-in seven times faster. — Richard E
The only oddball supposition could be that all three of my high-end systems have always saved excruciatingly slowly with PSB by some Bug, and the plugin fixes The Bug. This seems absurdly dubious, to say the least.
A few readers have written to say they can detect no advantage to the DisallowFlateCompressedPSD.plugin. Which, by definition, cannot be unless there is a factor involved which does not occur on any of my machines, thus offering hope to the afflicted users.
Speed gains with Photoshop CS5 with/without DisallowFlateCompressedPSD.plugin
Gains apply only to multi-layer files with image data on two or more layers.
Users reporting no improvement could find the conundrum caused by sorts of factors: a configuration error (with the plugin or otherwise), a failure to install correctly, use of an older version of CS5, a different OS version (I used 10.6.7), or some other unknown factor, such as a Bug. Or low memory that degrades both with/without results.
For example, one reader wrote to say that he had to reboot to turn the plugin off. I told him this made no sense. Later he revealed that he had moved it from the Extensions folder up one level into the Plugins folder.
Observing no change cannot be, because by definition, there must be a change if the plugin is working and the drive is reasonably fast, because without the plugin, saving as PSB is CPU-bound, and no CPU in existence today has enough grunt to save PSB quickly (without the plugin).
Some users could be timing incorrectly: use a timer (clock) for real time, do not rely on Photoshop’s Info palette, because it’s not accurate.
Other than that, I can’t diagnose all the user testing or configuration errors out there, or rule out something like a bug in Photoshop. Nor can I account for some file variant which defeats the gains for unknown reasons.
But I can explain what to look for, at least most possibilities, so read on.
Test using multi-layer files with image data on two or more layers.
CPU-bound without the plugin
Without the DisallowFlateCompressedPSD.plugin, saving large files is CPU-bound to a single CPU core.
Which means that one CPU core is pegged at 100%, and the Save runs as fast as that one CPU core can compress the file: very slowly, even with a 3.33GHz Xeon. During this time, I/O speed shows as zero in Activity Monitor for long periods:
CPU and I/O activity WITH the plugin
With the DisallowFlateCompressedPSD.plugin, the time to save is I/O bound, meaning that it runs in proportion to drive speed, up to a point. The CPU might still be mostly utilized (for a short period of time), but it’s not pegged-out at 100% for a long period of time, and the I/O speed is far higher. Like this:
What no speed gain implies
If gains are not realized, something is by definition wrong with the setup, or the test.
All of the following are possibilities to explore:
- The process is I/O bound to begin with, therefore no gains can be had with such a slow drive. Get a faster drive.
- There is an installation problem or bug such that the plugin is not active.
- There is some other environmental characteristic that defeats the function of the plugin, or otherwise slows down Photoshop.
- Use of Photoshop CS5 in 32-bit mode, which defeats direct use of more than about 2GB of memory.
- Configuring memory usage in a way that forces both reads and writes while saving, thus seriously impairing save speed.
Verifying the plugin is active
Confirm:
- Compare the saved file size with/without the plugin (Save As...). If the file sizes are the same, then the plugin was not invoked. Only if the file sizes are significantly different does this confirm that the plugin was active; the file size will be larger for the file saved with the plugin.
Verify that saved file sizes differ with/without plugin - Use Activity Monitor to observe CPU usage. If one CPU core is consistently pegged at 100% at low I/O speeds, then compression is occurring and limiting the save speed; the plugin is not being used, or is somehow disabled or broken.
- Use Activity Monitor to observe disk throughput. Speed should be a large fraction of the potential drive speed, e.g. 300-400MB sec on a RAID that can do 400MB/sec.
- Verify that virtual memory paging is not occurring (Page outs = 0.0), and that there is ample system memory that is marked Free— at least 2GB of Free memory.
Verify that Free memory is at least 2GB, and Page outs = 0.0
Notes from Adobe
From the Photoshop senior QE manager Adam Jerugim:
- Plug-in placement doesn't matter as long as it is anywhere in the plug-ins folder (we suggested plugins/extensions mostly for housekeeping purposes)
Users need to actually quit and restart the app to see the plug-in work (those instructions are on the KB doc) - There's little to no benefit to saving smaller data sets (smaller images) with the compression off – I would expect little to no performance gain in these cases
- Users who aren't seeing a benefit of the plug-in are likely suffering from one or more of the following: limited file I/O bandwidth/speed, limited disc space, limited access to RAM, or files that don't benefit from being saved without compression (smaller ones for example).
- As you mention above, there likely isn't a bug that caused the slowdown to begin with and that the reason people aren't seeing a gain is not due to a bug but likely a configuration error (or in the case of smaller files, an expectation error. ;)
