Last year I wrote a post comparing build times using an SSD and a traditional hard disk. One of the conditions that I tested was using an encrypted home directory, and was surprised that encryption added 11% to my build times — about the same as using a “spinning rust” drive.
That was Xubuntu 12.04, which used eCryptfs, a FUSE filesystem, to handle encryption. At the time, I posited that the buffer cache was holding encrypted data blocks, so you paid a “decryption tax” every time you accessed one. Xubuntu 14.04, however, provides an option to enable full-disk encryption as part of the installation. Since this hooks more tightly into the kernel, I wondered if the decryption tax was still present. This called for another day of testing.
For this series of tests, I'm using my HP ProBook 640-G1:
- Intel i5-4300M @ 2.6 GHz, 2 cores, hyperthreaded
- 800 MHz FSB
- 8 Gb RAM, 3 Mb L2 cache
- Samsung 840 SSD
- Xunbuntu 14.04 LTS 64-bit
And as a test subject, I'm building the Spring Framework 3.2.0.RELEASE. In my last test, it showed the biggest difference between SSD and platter, as well as the biggest difference between encrypted and non-encrypted access.
I tested three scenarios:
- Standard Xubuntu 14.04 install, no encryption.
- Home directory encryption (eCryptfs, running in userspace).
- Full-disk encryption (dm-crypt, which runs — I believe — in the kernel).
As before, I pre-fetched all dependencies and disconnected from the network. Each timing is the average of two
runs. Between runs I cleaned the build directory, TRIMed the filesystem, and rebooted to clear
the buffer cache.
Here, then, are the numbers. Execution time is wall-clock time in seconds, as reported by Gradle, because that's what we really compare about.
| Execution Time | Difference from baseline | |
|---|---|---|
| Baseline | 288 | – |
| Encrypted home directory | 300 | + 4.2 % |
| Encrypted filesystem | 295 | + 2.5 % |
I'm not sure why the penalty of an ecrypted home directory was lower this time around, but it's still there. And the full-disk encryption is a lower penalty, as expected, but again it's still there. So you still have to make a tradeoff between performance and protection. But given the numbers, protection should win.
At the end of my earlier post, I suggested that there's no substitute for RAM, and the ability to maintain a large buffer cache. I'm not sure that argument applies with a project as big as Spring. After each build, I cleaned the directory and ran a second build, figuring that 8Gb should be enough RAM to maintain everything in the buffer cache. The numbers, however, tell a different story:
| Execution Time | Difference from baseline | |
|---|---|---|
| Baseline | 284 | - 1.4 % |
| Encrypted home directory | 294 | + 2.1 % |
| Encrypted filesystem | 289 | + 0.3 % |
Yes, a slight improvement over the previous runs, but not much. I think this might be due to the fact that compilers produce disk blocks, rather than consume them — reading existing blocks is a small part of the overall execution time.
