FileVault Performance

With Lion sporting a more usable version of FileVault I was curious about its performance impact. I'd enabled FileVault on my personal machine and subjectively felt a performance impact, but I needed to quantify it. I put together a number of tests to do just that.

For all of these tests my test platform is a 15-inch MacBook Pro with a 2.2GHz Sandy Bridge Core i7 from early 2011 with an Apple branded 256GB SSD. In these tests I was primarily concerned with two things: how performance is affected, and what sort of extra load FileVault encryption places on the CPU.

Our first test is a simple file copy. I've got a directory of 2200MB worth of RAW files from a Nikon D700. I copy the folder from the SSD to the same SSD and report performance in MB/s:

FileVault Performance - 2200MB File Copy (MB/s)

With FileVault enabled we take a 24% performance hit, hardly insignificant. Average CPU utilization during the file transfer actually dropped with FileVault enabled from 8.5% to 4.5%. I suspect the reason for the drop was the slower overall transfer rate. It would appear that FileVault, at least on a quad-core Sandy Bridge CPU has absolutely no overhead here. Given that Apple near-universally uses AES for symmetrical encryption, it's reasonable to assume here that FileVault is taking advantage of the AES-NI instructions on Intel's Core-i series of processors.

Our next test tested one of Lion's new features: threaded conversations in Mail. We timed how long it took to launch Mail and open a single email thread with 42 replies. If you've used OS X Mail in the past you'll know that CPU utilization goes insane if you're working on a thread with dozens of replies. The same is definitely true for threaded conversations in Lion.

FileVault Performance - Open 42 Reply Email Thread - Time in Seconds

Thanks to the MacBook Pro's SSD both setups complete this task pretty quickly. There is a penalty associated with FileVault though - around 9% in this case. Peak CPU utilization was similar on both systems, 100% of four threads on the eight thread Core i7.

I grabbed a screenshot of the CPU utilization graph in Activity Monitor during this test for both setups:


CPU Utilization: No Encryption (left) vs. FileVault Enabled (right)

While the two vary slightly, you can see that overall CPU utilization appears to be similar regardless of whether or not encryption is enabled.

Our third test is actually one of our standard OS X CPU benchmarks - we time the import of 203 RAW images into iPhoto. This task is impacted by both CPU and I/O performance:

FileVault Performance - iPhoto Import - Pictures per Minute

Despite the I/O dependency, there's virtually no performance impact to enabling FileVault here.

Our final tests are raw I/O tests using Quickbench. I focused on 4KB and 8KB random read/write since those are the most common transfer sizes for random file access. And for sequential operations I focused on 128KB transfers, again optimizing for common sizes.

FileVault Performance - Quickbench 4KB Random Read (MB/s)

FileVault Performance - Quickbench 4KB Random Write (MB/s)

FileVault Performance - Quickbench 8KB Random Read (MB/s)

FileVault Performance - Quickbench 8KB Random Write (MB/s)

FileVault Performance - Quickbench 128KB Sequential Read (MB/s)

FileVault Performance - Quickbench 128KB Sequential Write (MB/s)

Overall the hit on pure I/O performance is in the 20 - 30% range. It's noticeable but not big enough to outweigh the benefits of full disk encryption. Note that under OS X there's still no way to take advantage of SSD controllers with FDE like the SF-1000/2000 series and the Intel SSD 320.

FileVault Safari, iChat, TextEdit, Preview, QuickTime X
Comments Locked

106 Comments

View All Comments

  • steven75 - Friday, July 22, 2011 - link

    "The fact is Windows/Office is really only expensive if you are building your own computers and installing your own OS"

    You seem to be implying that Office comes free with a pre-built computer when it in fact doesn't ever.
  • anactoraaron - Sunday, July 24, 2011 - link

    wrong. I know I shouldn't feed the trolls but when office 2010 came out my local office depot (and likely every office depot) had at least one pc with the full version of office 2010 on it. It was some kind of promotion they ran for about 2 weeks.
  • tipoo - Wednesday, July 20, 2011 - link

    Apart from the new animations in Safari, is performance improved any? Any word of it getting GPU acceleration?
  • name99 - Thursday, July 21, 2011 - link

    My experience was that it ran the IE Paintball demo 25% faster, and the end result showed no visual artifacts. So, an improvement on 5.0, but still nothing like the HW acceleration performance of IE.

    On the other hand, I've yet to encounter a site (apart from the IE demos) where this actually matters...
  • name99 - Thursday, July 21, 2011 - link

    Oh, it also, if you care, has elementary support for MathML. To be honest, however, the support is REALLY limited. The typography looks like crap, and anything even slightly fancy looks even worse --- eg long bars over symbols, large surds, etc.
  • tipoo - Friday, July 22, 2011 - link

    Thanks. Yeah, its GPU acceleration doesn't seem as expansive still as other browsers, judging by canned benchmarks I've run it through. IE9 and FF5 are still far ahead in GPU acceleration, Chrome and Opera are getting there, Safari 5.1 is still last.
  • EnzoFX - Wednesday, July 20, 2011 - link

    I think it's pretty unfair to compare Windows full-screening to Lion's. Full screening in Windows is not a feature at all IMO, it is the equivalent of dragging the window size out to the size of the screen. You do not gain any functionality whatsoever (usually just a lot of empty space, which was never in Apple's radar before). This kind of full-screen functionality has been present in OS X long before Lion, though it was often more manual, having to drag the window size out.

    But as you say, Apple has added functionality and it's become it's own separate feature. I think the comparison is pointless.
  • SmCaudata - Wednesday, July 20, 2011 - link

    True full-screen in Windows only happens with games, certain video players, and select other apps. I personally so no use for full-screen for most computer applications.

    Also, the comparison is valid because even in those areas where Windows does use full-screen, the other display still works. I can have a full-screen movie on one monitor while I do whatever I want on the other.

    I really fail to see how Apple's implementation has "added functionality" that didn't exist in other OSes before. The article talks about using gestures instead of minimization... isn't that what Alt+Tab and Win+tab already did?

    There are certain things that Apple does do well. Their dock was something that MS obviously took inspiration from for W7. This implementation of full-screen seemed pretty limited IMO.
  • name99 - Thursday, July 21, 2011 - link

    I suspect that the multi-screen hiccups with full-screen are purely temporary.
    We have seen problems like this before --- for example when multi-user GUI support (the rotating cube thing, to allow new users to log in to a mac) was first added, it didn't take long to discover that various iLife apps didn't behave properly. (I forget the details, but I think both iTunes and iPhoto wouldn't launch for the new user.)

    It's one of the drawbacks of Apple being so secretive, even internally, that you get these sorts of crossed signals. But the issues usually get fixed, and if they are very visible, they usually get fixed soon.

    I'd say, right now, the appropriate response is to assume this is a screwup, not go into conspiracy theory mode about how this is a plot by Apple to eventually remove multi-screen support.
  • Uritziel - Friday, July 22, 2011 - link

    LOL. As if a company spearheading Thunderbolt would aim to remove multi-screen support.

Log in

Don't have an account? Sign up now