Women in Technology

Article:		An Unencrypted Look at FileVault
Subject:		FileVault performance tax
Date:		2003-12-22 01:07:13
From:		anonymous2
Response to: FileVault performance tax
OS X has an order of magnitude worse performance on basic operations. That means 10x slower than other operating systems on the same hardware (I only mentioned Linux earlier for a performance contrast; I in no way advocate Linux over Mac OS; kernel performance is only one factor in the worth of a system). Doing benchmarks for basic kernel ops is simple. For example, to determine system call overhead, execute getpid() 10 million times, count the number of cycles for all calls and divide by 10 million (understand that you include some libc overhead in this number too, but if you are smart you can avoid that). Repeat for Linux. You'll see what I mean. If you want to know why the difference is 10x, look at the implementations in the two kernels. Once is focused on performance. The other does everything wrong for performance. But if an application spends only 5% of its time executing system calls, it doesn't matter, right? Not so fast ... the OS X kernel has large TLB and cache foot prints which affect all applications. And back to the encryption overhead. It is simple math. If the kernel were very fast, you would have to notice encryption overhead. It can only be unnoticeable when the overhead is dwarfed by other factors. I'm not going to publish benchmark numbers for Mac OS X. I'm not one of the many Mac people who try to earn fame by showing how poorly Apple implemented something. Thus why I remain anonymous. I'll publish something if I have an improvement to report (like how to fix the problems, and the performance benefit of the improvement).

Showing messages 1 through 1 of 1.

• FileVault performance tax
  2008-07-21 15:50:00  softweyr [View]
  
  
  I know this is age-old, but I want to reply just in case somebody else trips across this drivel. The Linux kernel guys long ago decided to "micro-optimize" certain trivial Linux system calls, including getpid(), so getpid() is no longer useful as a kernel micro benchmark on Linux. The first time you call getpid(), it does the syscall and retrieves the actual pid, every time after this it uses a cached copy of the pid. This makes getpid() useless as a microbenchmark to compare Linux to any other system, and was a waste of time for real applications which are unliked to spin on getpid(), but an indication of the Linux mindset in optimizing silly things that don't matter.