Optimising Parallels performance for development

I use the wonderful Parallels 6 to perform all my Windows development. (I find working on a Mac makes Windows development a lot more bearable - at least for this old Unix-head).

In general, Parallels works superbly (and is reported to perform a lot better than VMware, if you believe the hype). However, for operations like rebuilding a large, complex C++ source tree, the virtual machine performance lagged a long way behind a native machine. Large compiles can take more than twice the time of a real Windows PC. Clearly, this taxes the host machine hard: hammering CPU, memory, and disk at once.

This problem exhibits on my four core Mac Pro with as many resources as I could throw at the problem, as well as on my more humble MacBook Pro.

I performed a number of experiments to work out how to fix this:

• Tweaking the allocated CPU cores, memory, and disk space
• Tweaking the settings for the virtual hard drive
• Network building from host mac file system

None of these made much difference. In fact, I was somewhat surprised that operating on a networked disk was fantastically slower. That was a shame, as it would be advantageous to share a single source tree with my Xcode development for cross-platform development. (As it happens, I manage this by having a Windows-side git clone of the git repo on the Mac side).

However, I've now managed to get my compile times right down. Here's how.

Do bare in mind that these tweaks are in addition to the obvious steps you should take with any machine:

• Have as fast a CPU as possible.
• Throw as many CPU cores as you can at the problem - builds can be parallelised very easily.
• Throw as much memory as you have at your disposal at the problem.

1. Swap the swap

The factor slowing me down the most turned out to be the Parallels virtual disk that Windows was running on. First, the swap file was hosted on it. So I made a second virtual disk, and pushed the virtual memory off onto it. That made a small, but appreciable difference.

2. Only ever use fixed size disks

In your disk settings, do not use automatically expanding disks. That's just another overhead for the computer to manage whilst accessing disks. Create a fixed size blob of disk space and run with it.

3. Use a virtual SCSI disk

This is the big one. So pay attention at the back.

It seems that Parallels can emulate a SCSI disk far, far faster than it can emulate and IDE disk. However, it defaults to creating IDE disks. I believe that this is to make installation of Windows simpler, as you don't have to fettle with custom SCSI drivers during installation.

You can't just switch the main disk from IDE to SCSI, though. Windows has a minor eppe and refuses to run if you do that. I couldn't be bothered to wipe it all and try to reinstall on a new SCSI virtual disk, so I added yet another large SCSI virtual disk for my source trees and checked out onto that disk.

Remember: it's a fixed size, non-expanding SCSI disk.

With this configuration the build simply screams in comparison to building on the virtual IDE C: drive.

I hope you find this information useful!

iOS: The Enigma Squares (1.2)

The Enigma Squares version 1.2 is available in the App Store now. Amongst other excitement, it adds Game Center support. You can now share your achievements and high score with other players. Woo hoo.

So far, I'm very impressed at how far players have got. I'm glad the game is providing an interesting challenge!

More interesting updates are in the pipeline...

iOS: Packaging apps store submissions from the command line (my zip broke)

How to package iOS apps for submission to iTunes Connect from the command line.

I'm a firm believer in the power of the command line. I like my GUI tools as much as the next man (as long as he's a bearded Unix guru from the 1970s). But for sheer power, repeatability and flexibility you just can't beat a good script.

Which is why every project I work on has to have a simple single script that configures, builds, and packages the code, creating a well-named payload that can be installed/submitted/deployed. I feel a lot safer about the quality of a release if it's generated by a tried-and-tested script, rather than by a series of button clicks in a series of separate tools.

You know it makes sense.

iOS projects submitted to the App Store are effectively zip files with a particular directory structure. You can drive Xcode with the xcodebuild tool to build and link your distribution version of an iOS app.

However, whenever I tried to zip the project up from the command line, the Application Loader utility (what you use to submit your app to iTunes Connect) just gave bizare errors.

The CodeResources files must be a symbolic link to _CodeSygnature/CodeResources. Make certain that the bundle is on a locally-mounted volume...

Application failed codesign verification. The signature was invalid, or it was not signed with an Apple submission certificate.

Well, that's nice gibberish. Not.

However, a zip archive created using the Finder's "Compress" menu entry worked fine. Very frustrating.

Don't fear! I fixed it. Here's how to do it in your very own build script: your zipper is broken; throw it out. Use ditto instead. Here's the line from my build script:

APP_FILENAME=/path/to/build/Application.app

PACKAGED_FILENAME=MyGoodPackagedFilename.zip

ditto -c -k --keepParent --rsrc "$APP_FILENAME" "$PACKAGED_FILENAME"

Enjoy your build scripts.

Becoming a Better Programmer

My Becoming a Better Programmer presentation given at ACCU 2011 has been very popular recently. It's one of the most-viewed presentations on slideshare this month.

At the time of writing, there have been more than 12,500 views of the entire presentation.

That is both exciting and flattering - and nice to know that developers truly do care about improving their skills. And nice to know that I have been able to help.

Check it out here.

Writing: Relish the Challenge

The May issue of ACCU's C Vu magazine will be hitting doormats any moment now. It contains the latest instalment in my Becoming a Better Programmer column. This one's called Relish the Challenge, and is an encouragement to stay motivated and challenged, to seek out new things, and to avoid becoming stale and staid as a developer.

I hope it's useful. For your stimulation, I've added the final questions from the article to the end of this blog post.

The PDF version of the magazine will be available for download by ACCU members shortly.

The cover I created for this month's issue is quite dense and busy. I wonder if that's any reflection on the designer?

Questions

1. Do you have projects that challenge you and stretch your skills?
2. Are there some ideas you’ve thought about for a while, but not started? Why not start a little side-project?
3. Do you balance ‘interesting’ challenges with your ‘day to day’ work?
4. Are you challenged by other motivated programmers around you?
5. Do you have a broad field of interest that informs your work?

iOS: The Enigma Squares

My first personal iOS project has finally seem the light of day. Please welcome into the world The Enigma Squares. It's an interesting (and dare I say it) entertaining block-moving puzzle game.

Check it out on iTunes here.

I've produced plenty of iOS projects for my company. But this has been an entertaining personal side-project, to keep me busy through those long spring evenings.

It is actually a version of a game I first wrote (ahem) 20 years ago. Back then it was written for the Acorn Archimedes, and I sold it to a magazine for inclusion on their cover disk (remember those?) This version is a little more polished, a little more challenging, and a lot more fun.

The code's a fair bit better too, but that's another story. One that I'm sure I'll tell one day...

Let me know what you think of it!