fbpixel
  
« Previous topic | Next topic »  
Reply to topic  
 First unread post  | 5 posts | 
by StephenFitzpatrick on Thu Dec 01, 2011 2:29 am
User avatar
StephenFitzpatrick
Forum Contributor
Posts: 580
Joined: 01 Jun 2006
Location: California
Member #:01795
I've been trying to optimize PS (CS5.1 64 bit, Windows 7) and noticed (using Process Monitor) that some plugins create numerous, rather large, temporary files (100s of MB) on arbitrary drives. e.g., I've seen it create files such as A:\3540_1226448_MVM_12.tmp - the common part is the "MVM" (something to do with Mondo plugins, whatever those are).

The downside is that A is my slowest drive, so presumably this choice of location is slowing down the filters. I have plenty of space on other, much faster drives, but can find no way to force the filters to use those. (It doesn't matter what the settings are for memory allocation, scratch drive, page file or tmp/temp folder.)

I imagine I'm not the only one who bought a small, fast drive for PS scratch and paging, and a large, slow drive for movies and music.

Another quirk. If you set PS to use C as its scratch drive, it will actually use whatever folder is set as the Windows TMP folder (in the Windows environment variable). It will do this even if the TMP folder is not on the C drive.
 

by Royce Howland on Thu Dec 01, 2011 12:49 pm
User avatar
Royce Howland
Forum Contributor
Posts: 11723
Joined: 12 Jan 2005
Location: Calgary, Alberta
Member #:00460
Congrats, you've found another one of the ugly little things buried within Photoshop. :) Mondo is an Adobe Photoshop plugin development framework. Plugins are used for many functions in Photoshop (and even in Bridge), and many plugins are built on this Mondo framework. MVM stands for "Mondo Virtual Memory", from what I have read, and it seems that these plugins use their own system of memory management completely separate from the main Photoshop virtual memory & scratch drive system.

Cutting to the chase, unfortunately it appears that there is no way to directly configure or control where these MVM files are stored. The Mondo framework seems to have some hardwired memory management behavior that's incredibly obsolete, buggy, poorly thought out, or all 3. You can spend hundreds of $ on 64-bit OS, loads of physical RAM, SSD's or fast disks like Velociraptors or RAID stripes. And then spend dozens of hours researching and tuning Photoshop, Windows, etc. And the MVM plugin framework will ignore all of that and just spew its temp files all over the place, across any mounted storage devices it can see on your system. Some of these MVM files can be several GB in size for certain plugins, and while they're usually cleaned up when Photoshop exits that doesn't always happen. So these large files may slowly accumulate over time.

There's loads of discussion of this situation around the web, including on the Adobe support forums. On the latter, there's some of the usual "ignore the reports", "blame the user", "it guaranteed can't be our software's problem", and "distract them with an irrelevant tangent" that we've come to know and love from most vendor support services. :) See this thread for example, for a good summary of reports of the issue and how various tactics don't fix it:
http://forums.adobe.com/message/3257006

The only credible info I've been able to track about some kind of method to the madness of where these MVM files appear, is that it seems to correlate with distributing them according to storage volume free space. Unfortunately what this means is that if the majority of your free space is on slow devices, or worse external ones like USB drives that go to sleep, performance will suffer when the Mondo framework fires up. And it can fire up even when you don't think you're doing anything to trigger a plugin, because some plugins may initialize themselves when you just launch Bridge or Photoshop, or do something as simple as open a certain type of file like a .PNG image.

At least in the above linked thread, by August of this year an Adobe developer finally acknowledged that "it may be a bug", and that "someone else is looking into it".

The 2nd item you describe (setting PS scratch to the C: drive but then having it actually go to another device corresponding to the setting of the Windows TMP folder), is a new one on me. But I guess I'm not surprised by it, either...
Royce Howland
 

by E.J. Peiker on Thu Dec 01, 2011 5:03 pm
User avatar
E.J. Peiker
Senior Technical Editor
Posts: 82556
Joined: 16 Aug 2003
Location: Arizona
Member #:00002
As Thomas Knoll once said to me "Photoshop is a memory and system resource pig" he said that in light of a discussion we were having about Lightroom which is more efficient with resources.
 

by StephenFitzpatrick on Fri Dec 02, 2011 1:40 am
User avatar
StephenFitzpatrick
Forum Contributor
Posts: 580
Joined: 01 Jun 2006
Location: California
Member #:01795
Thanks.

So the strategy for working space seems to be: use the filesystem even if there's plenty of RAM available; and use the slow drives even if there's plenty of space on the fast drives. Marvelous!
 

by Royce Howland on Fri Dec 02, 2011 9:48 am
User avatar
Royce Howland
Forum Contributor
Posts: 11723
Joined: 12 Jan 2005
Location: Calgary, Alberta
Member #:00460
Exactly. Giving the benefit of the doubt that somebody in the past was actually trying to think through the design of the observed behavior, perhaps it made sense back in the day. Everything was 32-bit, CPU's were a lot slower with fewer cores, capacity was smaller, storage devices were about equally slow, perhaps project files weren't so big. So it made sense to break up a memory image into chunks and spread them around a number of different hard disk spindles, depending on where the most free space was available. That's the most coherent theory I've seen on why the 16 MVM files (and there do seem to be at most 16 of them active at one time) can appear in different numbers, on different disks, at different times.

But in the modern era of 64-bit, large amounts of physical RAM, large storage capacities, and certain storage devices like SSD's far outstripping the performance of 5400 RPM "green" disks, this strategy no longer makes sense. And it certainly doesn't make sense to give an informed user zero control over the behavior of the memory management system. There may or may not be "bugs" in the Mondo framework contributing to the behavior, but certainly from a design standpoint it can't be considered anything other than poor, now...
Royce Howland
 

Display posts from previous:  Sort by:  
5 posts | 
  

Powered by phpBB® Forum Software © phpBB Group