About
PD Tweaker is an Application Enhancer (APE) plugin that addresses a few shortcomings in the initial release of Parallels Desktop (build 1848) for Intel-based Macintoshes.
It has two major features which can be enabled separately:
Optimizes caching for HDD and SAV files
A much better caching strategy for these files is actually no caching at all. Caching large files can be harmful to your Mac's overall performance. HDD files do not need caching because the client OS will already have a cache layer. SAV files are streamed in and out and don't need to reside in the disk cache.
-
Always writes HDD and SAV files all the way to disk
Your data is precious. Especially data like a HDD file that took you hours to install and configure. Shouldn't you treat it that way?
Download
Download PD Tweaker 1.0 here and double-click to install.
You'll need Unsanity's Application Enhancer to use it. PD Tweaker works with version 2.0, but 2.0.1 or later is recommended.
Known Issues
Suspending and resuming your virtual machine may be slightly slower with PD Tweaker enabled. This is a side effect of how Parallels Desktop is doing its reads and writes to the SAV file -- it is not optimized for page-sized reads. I might try to optimize this further in a future version.
APE 2.0 has a couple of minor interface bugs that may affect you. Here's a list, with the workarounds.
- Can't double-click the APE file - Sometimes after a fresh install of
APE the double-click support doesn't work. If it doesn't, you can run System Preferences
and manually load PD Tweaker by clicking the "+" button in the
Application Enhancer preferences.
"Install for this user only" doesn't do anything - This happens when the folderFixed in APE 2.0.1~/Library/Application Enhancersdoes not exist. Either create it manually, or install for all users.PD Tweaker seems to load into every app! - It's only supposed to load for Parallels Desktop and ImageTool. The next version of APE will fix this problem. In the meantime, this additional loading is harmless -- PD Tweaker is dormant in every app except for these two.Fixed in APE 2.0.1
Version History
- PD Tweaker 1.0 was released on June 22, 2006.
Why does it disable caching?
Perhaps you've seen your Mac drag to a crawl as Parallels Image Tool converts a HDD image. Or maybe you've noticed lackluster performance from your Mac during or after a session with Parallels Desktop. It's not your fault, and upgrading to 2GiB of RAM won't help either. Parallels Desktop should -- but does not, as of the current release -- explicitly disable disk caching for the two large files (HDD and SAV) that it works with.
Caching very large files is actually harmful to your Mac's overall performance. And a multi-gigabyte HDD image file certainly qualifies as very large!
Why is it harmful? Well, what happens is that the OS will start caching pages of that very large file in memory. Mac OS X has an aggressive disk cache layer that will happily try to cache the whole darn thing in RAM. But for very large files that don't have disk caching disabled, the end result is that it happily fills up all available RAM with data from that image file. Worse, because Mac OS X uses a unified buffer cache (UBC), application code is shared with the disk cache. So if you haven't used other apps in a while it will actually page those out too to make room for your HDD file. This naturally causes you no end of grief when you switch out to another application.
Stirring up a page storm isn't the only problem. Disk caching does almost nothing for Parallels' performance. In typical usage scenarios, 99% of the data that's being cached from the HDD file will actually fall out of the cache before it's ever used! So the caching is really a waste.
(Don't believe me? It's true. HDD files do not need caching because the client OS will already have a cache layer which is optimizing accesses to the disk. SAV files are created when you suspend or resume a virtual machine, and written and read exactly once.)
For the programmers who are reading this, the solution is to explicitly call
fcntl(F_NOCACHE) on large files, or any file that you are accessing
in a stream with relatively large reads. And that's exactly what PD
Tweaker does.
Further reading from Apple:
File-System Performance Tips: Cache Files Selectively
"Disk caching can be a good way to accelerate access to file data, but its use is not appropriate in every situation. Caching increases the memory footprint of your application and if used inappropriately can be more expensive than simply reloading data from the disk."
Why does it add an explicit sync?
Whenever you're working with a very large file which is difficult or time-consuming to replace, it's important to make sure that it's flushed all the way out to permanent storage in a consistent state.
Closing the file just gets it out of your application's memory, but it
could linger in the disk cache. Calling fsync flushes it from
the computer to your hard disk. But your job's still not done. It may actually
still be stored in your hard disk's on-board write cache! If the drive loses power
before it's flushed its own cache -- either due to a power failure, or perhaps
because it's a USB or FireWire device that you've unplugged -- you are still
at risk of data loss. (For an in-depth explanation, see
this
description from Dominic Giampaolo.)
Mac OS X addresses this problem with another fcntl selector:
F_FULLFSYNC. PD Tweaker will make this call automatically
when Parallels Desktop calls fsync(), and again when the file is closed. This
helps prevent corruption of your HDD and SAV files.
(In case you were wondering, this has nothing to do with Jon Rentzsch's recent problem. He actually had a physically bad sector on his disk.)
Have you contacted Parallels about all this?
Yes. I've sent them a couple of emails and haven't heard back yet.
Update 6/27/2006: I recently got a brief response, and heard anecdotally through another source that most of the team was in fact away last week. At their request I've re-sent my original emails, so there might be some movement on this issue soon.
They seem to be normally pretty responsive, so I'm sure that eventually they will incorporate these features into a future version of Parallels Desktop. But in the meantime, I just really needed to run Parallels without paging up a storm. I fully expect PD Tweaker to be obsolete very soon, but I just thought I would share.
Who knows, maybe it'll light a fire under them to fix it sooner. :-)
What else could be improved in Parallels Desktop for Mac?
Here's a short list of relatively easy-to-improve things that I've noticed.
Graphics Speed
The initial release of Parallels Desktop flushes way more of the graphics port than it needs to. Run Quartz Debug, enable flash-on-update, and boot into Windows XP. You'll see that Parallels rarely updates less than an entire scan line, even if only a small portion of that line has changed. Instead of a flash right around the area that changes, you'll see a big horizontal flash that's the entire width of the Parallels Desktop screen.
With Quartz Debug still active, now open Notepad (or, if you have it, Microsoft Visual Studio). Start typing. You'll see the entire window flash for every single character! Let's do the math here to show how bad this is. Rather than flushing roughly 16x16 = 256 pixels to draw a character, on my MacBook it's actually flushing as many as 1280x800 = 1,024,000 pixels instead! That's a whopping 4000 times as much data being moved around than is actually necessary.
As it happens, all the Intel-based Macs actually have very fast RAM and wide buses, and they handle that load surprisingly well. But it introduces a small but noticeable lag (on the order of a few milliseconds) to your typing. Since almost all of my Windows XP usage involves writing code in Visual Studio, I really feel the pain of this one.
Fixing this correctly is beyond the scope of PD Tweaker. It would involve studying the interaction between Windows XP, the video card emulation, and the application's display code -- which pretty much means the Parallels team has to do it.
Boot Cache
Parallels could easily and transparently provide a service to the client OS similar to the Mac OS X boot cache to make client OSes boot faster.
This could be done in PD Tweaker without too much trouble. Maybe in my nonexistent free time I'll look into it. :-) Hopefully the Parallels team will beat me to this one.
Not that much else
Really, it's actually a very good product. And I don't begrudge them a few performance goofs -- they didn't start as Mac developers.
Parallels Desktop is an excellent product and a very fine (and most importantly, stable) first release and I highly recommend it. And I'm sure that future revisions will clean up all of these issues and add a lot more great stuff.
Is the source code available?
Yes! It's available under a simple Creative Commons attribution license. You may use it in any way you like, as long as you give credit to Multisolar and provide a link back to this page (http://www.multisolar.com/software/PDTweaker/).

This work is licensed under a Creative Commons Attribution 2.5 License.
You will need to install Unsanity's APE SDK to build it.
Acknowledgments
The icon is partly derived from drawings in the flash game at SP-Studio.de. The source code includes ClickableText.m/h which was written and placed into the public domain by Ben Haller of Stick Software, who makes a lot of nice little products. The PD Tweaker APE is based on Unsanity's example BeepMultiplier APE written by Slava Karpenko. I sent a couple of IM's to Rosyna while working on this, and he fixed two minor bugs that I ran into. Rogue Amoeba had absolutely nothing to do with this project, but Paul Kafasis sent me an awesome machine-gun toting stuffed amoeba a while back and I just wanted to give him a shout-out. Michael Simmons, author of PiXel Check, was the lone beta-tester.