Back to the Mac: OS X 10.7 Lion Review
by Andrew Cunningham, Kristian Vättö & Anand Lal Shimpi on July 20, 2011 8:30 AM ESTFileVault 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:
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.
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:
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.
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.
Facebook
Twitter
RSS
106 Comments
View All Comments
rs2 - Wednesday, July 20, 2011 - link
Okay, it makes sense on a touch device where your finger is actually making contact with the thing you are scrolling. But a mouse cursor is *not* a finger. It is not an analog for a finger. It is a different input paradigm entirely, and trying to make it behave as if the mouse cursor is your finger by making scrolling go backwards is stupid.It's good that they put in an option to disable the nonsense that is "natural" scrolling.
name99 - Thursday, July 21, 2011 - link
Not at all. The issue is simple : what is the metaphor?When I move my finger, am I moving
- the window container? OR
- the content?
Claiming that one is more "natural" than the other is as stupid as claiming that English is more natural than Chinese. It's simply that you are used to one and, like a good American, you simply cannot imagine that the world could possibly be different --- after all, Jesus spoke English.
rs2 - Thursday, July 21, 2011 - link
Not at all. There is no "finger" when using a mouse. Touch and mouse-driven are distinct input paradigms. If a touch-based interface ever scrolled content in the opposite direction that the user moved their finger, then people would say that it was broken. And rightly so. Moving content in the same direction as the touch is the intuitive operating mode of a touch interface.And similarly, moving content in the opposite direction of the scroll (or more accurately, moving the scrollbar in the same direction of the scroll) is the intuitive operating mode for a mouse-driven interface. By your logic scrollbars themselves should also be inverted.
As a side-note, a direct analog to touch style scrolling does exist in the mouse-driven paradigm, it is the drag operation. It is available in some things like Adobe PDF documents, and also work on any scrollbar. In this operation you choose an anchor-point, and then that anchor point moves in the same direction that you move, and it all makes sense. The problem with scrolling is that it has no anchor point, it is a distinct operation from a drag operation, and by conflating the two Apple has broken their interface. At least until they start incorporating touch into every computer they sell.
Mouse-driven and touch interfaces are not the same thing, and just because a metaphor makes sense in one does not mean that it also makes sense in the other.
Uritziel - Friday, July 22, 2011 - link
Agreed.CharonPDX - Wednesday, July 20, 2011 - link
On page 23 "Performance: Similar to Snow Leopard", you have a couple bar graphs comparing Snow Leopard to Lion performance. Unfortunately, you use a generic "compared to before as 1.0" metric, with no indication on a per-test basis whether higher or lower is better. In the Core 2 Duo graph, you talk about boot time skyrocketing, and the boot time graph for Lion shows Lion as "about 1.4" of Snow Leopard, yet you also talk about iPhoto having a "greater than 10% increase in performance", where the graph shows "about 1.1" of Snow Leopard. So in one line in the graph, higher is worse, in the other line, higher is better.You either need a per-test identifier (Higher is better / Lower is better) or you need to to standardize them all (so 'benchmark' ones would stand as-is, while 'timing' ones would use the inverse, so that both would be 'higher is better', or example.)
Deaffy - Thursday, July 21, 2011 - link
Did anyone check to see whether Apple has included a UI element to enable IPv6 privacy extensions for statelest address autoconfiguration?And did DHCPv6 to get IPv6 addresses from your ISP's cable via IPv6 finally make it's entry?
Deaffy - Thursday, July 21, 2011 - link
Oh yeah, and maybe the ability to query a name server via IPv6?kevith - Thursday, July 21, 2011 - link
they are more and more returning to the Linux it came from. Who knows, they might even go bact to open source:-)Omid.M - Thursday, July 21, 2011 - link
Anand/Andrew/Christian,If you right click on a YouTube video, does it say the rendering AND decoding is "accelerated" ? I thought Lion was supposed to bring that.
If this is now the case, it'd be enough reason for me to buy Lion and a new MBP 15". I can't stand the fans on my 2008 MBP 15 going nuts every time I watch a 30 second YouTube clip. The laptop gets unreasonably hot right now.
@moids
P.S. I'm not a fan of the way buttons appear on the upper borders of windows. There's no typical button "design" to signify that the text is clickable, at least not from the screen shots I saw in the article.
Omid.M - Thursday, July 21, 2011 - link
I guess it's disabled:http://www.macrumors.com/2011/07/21/adobe-suggests...