An Unencrypted Look at FileVault
Subject:   FileVault performance tax
Date:   2003-12-20 05:05:20
From:   anonymous2
The author is a bit wrong about why FileVault has no perceivable performance impact. He claims that Mac OS X is fast enough to handle the encryption/decryption with out user notice. This is not true. It is precisely because Mac OS X is so *slow* that you don't notice the encryption/decryption overhead. A Mac OS X system call has an order of magnitude more overhead than a Linux system call for example. And since there is already so much overhead in a Mac OS X kernel operation, adding the additional encryption/decryption overhead is unoticeable.
Full Threads Oldest First

Showing messages 1 through 10 of 10.

  • FileVault performance tax
    2003-12-21 17:22:15  anonymous2 [View]

    The problem is it is a tax all of the time. If it just happened when I expected it to slow down the system it wouldn't be so bad, I'd go out for coffee. *grin* But by taxing every little transaction it is like the Canadian VAT driving up the price and slowing down the whole economy. The fact is not everything needs the filevault protection but in most users cases they are going to not set it up properly. Sure they should put things like pictures, movies, music and non-sensitive data outside their home directory so it isn't in the filevault but then you are violating some of the whole concept of the user space. It is at cross purposes. Even worse is that the user's Library where lots of temp files, caches (e.g., Safari) and preferences are stored is inside the filevault. These files get lots of transactions and are heavily used. That's going to take a hit. I do not like it.
  • FileVault performance tax
    2003-12-21 07:42:53  anonymous2 [View]

    This is a worthless post without a single fact. What do you mean by magnitude? Which system calls? And how is OSX so slow? Facts and benchmarks please to prove your point. Otherwise ignore this guy.
    • FileVault performance tax
      2003-12-22 01:07:13  anonymous2 [View]

      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).
      • 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.
  • FJ de Kermadec photo FileVault performance tax
    2003-12-20 07:20:37  FJ de Kermadec | O'Reilly Blogger [View]

    Hi !

    First of all, thank you for your feedback !

    I am afraid that you read a part of the article somewhat too quickly. Indeed, I wrote that FileVault does not lead to a noticeable slowdown in a real-world business environment. Users who rely on resource-intensive video or audio applications, should take extra steps, as stated.

    I am afraid that your perception of the speed of Mac OS X does not reflect its real performance. Indeed, many studies have shown that its UNIX core is very fast ! You will find numerous links to such reports on the Apple site as well as on independent third-party publications.

    Mac OS X or its UNIX base alone, Darwin, are now used my many research labs to perform some advanced calculations that require stability and speed, as well as by some of the leading computer animation companies that require a OS and hardware capable of performing intense calculations.

    Again, thanks for your feedback.

  • FileVault performance tax
    2003-12-20 07:14:57  anonymous2 [View]

    would all that overhead in the kernal be the same that let's OSX run all sorts of business and creative apps that linux people would droll over?

    Sorry. just trying to keep things in perspective here. I just am remembering linus's crying about how apple "monolithic (or was it the other type of kernal) was "crap". Ummm linus, linux is good for a server and that's about it unless you are a übergeek that just likes to fiddle. What good is a leaner kernal to normal users if it doesn't run the apps they want or need?

    Bck on topic. I've used FV on my dual 2gig g5. I would agreee with the author. if you do "business" type work. then use it. If you do "creative" type work you may not want to.

    i've heard of improvments in 10.3.1 and 10.3.2 and i only have experience with 10.3

    • FileVault performance tax
      2003-12-21 15:03:51  tychay [View]

      It's the other way around. NT and Darwin have a microkernel and Linux has a monolithic. Not too sure if it is a big issue anymore since many of the advantages of a ukernel have been incorporated in Linux, very few things take advantage of the inherent advantages of a ukernel ("Classic" old Windows compatibility), and the slowdown of a ukernel vs. a monolithic gets marginalized as applications get more complex. (Certainly not an "order of magnitude" like the original flamebait claims.)

      Honestly, if Darwin were so slow, then why is the #3 fastest supercomputer using it? Certainly there are Linux drivers for the G5 now--heck, 64-bit support is now standard in kernel 2.6.

      BTW, Linux is far good for more than just a server. It makes the core of many excellent operating system distributions. It is an excellent and rapidly improving embeddable operating system (in fact, I think it will overtake WindowsCE at the rate its going). It now has even hooks for the beginnings of a serious real-time operating system.
      • FileVault performance tax
        2003-12-26 21:19:45  anonymous2 [View]

        I can't comment on NT but the original CMU and OSF Mach are ukernels, Apple xnu is not in the true sense. The FreeBSD "server" is not a real Mach server but bolts directly onto Apple's own variant of Mach so there is really no major slowdown there. Nevertheless, there is some overhead with making BSD system calls. Depending on what you want to do, task_self() might be more appropriate than getpid(). I'm also not sure how you actually timed the system calls. FYI, there are no release-quality kernels that will leave you with a working G5 Linux system, there is no accelerated OpenGL on NVIDIA cards and ppc64 64-bit Linux is not in any sense standard in kernel 2.6. Linux probably makes a poor choice if you want to do anything serious on your (Apple) ppc. As for the TLB overhead etc. pick up a good book on computer architecture and the ppc user manuals: the code for managing the TLB is very standard (read: same) across any operating system that will run on the ppc.
        • FileVault performance tax
          2004-09-29 17:52:42  rhigginbo [View]

          Interesting Link:

        • FileVault performance tax
          2004-09-29 17:48:11  rhigginbo [View]

          Industry research shows that most of the performance difference related to Linux and OSX are impacted mostly by HFS+ performance and TCP/IP throughput. Gnosis Software (a Linux-oriented company) has performed Linux benchmarks which detail the primary differences in performance.

          (Not sure what release of OSX or which version [server or client] was used. But, this benchmark is a good point for discussion.)