Pixelpope

With my setup I measured the performance of FileVault vs no encryption.

Conclusion: FileFault slows down the system by about 4%

Today I activated FileVault for protecting my private data in case (hope it never ever happens!) my MacBook gets stolen (or lost by stupidity).

FileVault works quite different in contrast to the Windows-like encryption, which works on the filesystem-level of NTFS. With FileVault on OS X you have no options on what directories or files to encrypt or not. It’s all (of your user folders) or nothing. OS X will take your whole user directory and put it in an encrypted sparse file which will be mounted as your user directory. This means, everything in your users’s folder is in there, including your media (iTunes library, GB-large video files), cache-files for applications. This also means, it will take some time — and as much free diskspace as you have data to encrypt. Same deal the other way around: You will need lots of free space if you once decide to turn FileVault off. If you don’t have enough, it won’t be possible, so think twice.

Now, since everything is encrypted and put into one single file, I was somewhat concerned about performance. Especially on a notebook, you don’t want to give performance = battery time away. So, I’ve done a very simple benchmark.

The benchmark

The setup

• 2006 MacBook Core 2 Duo @ 2 GHz, 1 GB RAM, 160 GB WD Scorpio harddisk, OS X 10.4.10 (Tiger)
• Personal files (and thus the FileVault file) about 40 GB

What I measured

I took a rared iso image (about 710 Mb, which extracts to about 2,1 GB), copied it to the (unencrypted) shared folder and a folder within the FileVault. This means the archives each were read and then unpacked to an unencrypted, respectively encrypted directory.

I unpacked each a couple of times with rar from the shell, afterwards deleted the unpacked folder, removed from trash and did it again.

Why did I chose this method? The file to be read and the files to be written are large and many enough to show some impact on the performance that is only based on the read/write performance, plus it puts some load on the cpu, which I think simulates real life application usage very well. After all, you don’t only copy files from here to there but it’s your application that writes and reads files while you use it, right?

How I measured

I turned off ClamAV and Spotlight, closed all windowed apps but one finder window and the process manager to minimize external factors. From the shell, I told rar to extract the archive, then switched to the already open process monitor, looked for the running rar process and opened the “information” window about that given process. This way it would stay open after the process finished and give the exact amount of time it took. Then minimized the activity monitor and focused the desktop to leave the unpacking alone.

This is no rocket science, but the numbers don’t go off by a lot, so I think they are somewhat meaningful.

The results

Here are the times it took for extracting each rar file.

Non-encrypted directory:

• 2:26.74 (146.74 secs)
• 2:26.19 (146.19 secs)
• 2:26.67 (146.67 secs)

The biggest difference is 0.55 seconds, which is about 0,37 % and thus neglectable small, I think.

FileVault directory:

• 2:32.08 (152.08 secs)
• 2:33.48 (153.48 secs)
• 2:32.46 (152.46 secs)

The biggest difference here is 1.4 seconds which is about 0,92%, which I believe is ok to use.

The difference between the two medians is 5.79 seconds, which means using FileVault encryption is about 3.9% slower than no encryption. On a brand new dual core. I expect this to be even more crucial on older machines.