| Article: |
An Unencrypted Look at FileVault | |
| Subject: | FileVault performance tax | |
| Date: | 2003-12-21 07:42:53 | |
| From: | anonymous2 | |
|
Response to: FileVault performance tax
|
||
| 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. | ||
Showing messages 1 through 2 of 2.
-
FileVault performance tax
2003-12-22 01:07:13 anonymous2 [View]
-
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.



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).