| Part 1 of this review is located here.
After reading through the first version of this post, some have asked for CPU intensive tasks such as Handbrake. Additionally, the first post didn't measure battery in a perfectly controlled fashion so this time around one of the experiments focused on that.
For these tests, I once again prepared the MacBook Air 11" 2012 with raw data sources for stressing the CPU. This included an 8gb raw DVD source files placed on the desktop to leverage the SSD's read speed as well as placing 40gb iPhoto library. Once the MacBook Air 2012 11" i5 was all setup, I once again cloned it to other MacBook Air 2012 11" i7 in preparation for the tests.
The tests include (a) a single cpu iPhoto database rebuild, (b) a multi-cpu Handbrake encoding, (c) a real world battery test lasting three hours of continued use, and (d) a handbrake with the i7 MacBook while in docked under a 27" apple display in the closed clam shape mode.
Part1 - iPhoto database rebuild
I have a very large 40+ gigabyte library for iPhoto (photos only as I have video's elsewhere) and it was really really sluggish. I initially though it was due to the hard drive not able to keep up with all the media, however after copying the iPhoto library to my MacBookAir i5 I found it shocking it was as slow and sluggish with the infamous spinning colorful beach ball like cursor. Upon discovering how to repair the iPhoto library (something I recommend everyone apply using this blog I additionally wrote ) I started to time the various repair processes simultaneously on both machines. The first repair was rather quick, about 20 seconds or so, and entailed rebuilding the permissions (the first option in the iPhoto repair dialog).
In most cases the i7 finished a few seconds quicker than the i5 -- except for one instance where it finished a few seconds later. I was intrigued and investigated further only to discover a running process was running and temporarily taking up about 20% cpu. After a bit of research, I discovered the running process was spotlight indexing parts of the drive. Clearly this process would distort the accuracy of any experiments by a small margin, so I dug further and discovered how to stop spotlight indexing temporarily with a small command line executed through the terminal app.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
To start it up again after all your tests, you can issue the load command as follows:
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
I'm not sure if spotlight is resource intensive to the point one looses 10 or 15% battery, but I may consider having a quick script so I can activate and deactivate it conveniently if it indeed uses valuable battery. With spotlight disabled, the i7 continuously and predictably completed the iPhoto permission repair routing a few seconds ahead of the i5.
Main Test - iPhoto Rebuild Thumbnails
This test was straight forward. I simply started iPhoto in repair mode (holding Command + Option while launching iPhoto) and started them both while also starting the timer on my iPhone.
Again, as I did in the previous blog's tests, I measured CPU temperature, fan speed, overall progress and the final finish times. The repair database process seems to be a single threaded process as only one CPU fired up to max capacity throughout the test as shown in this cpu monitoring tool called Menu Meters.
| | MacBook Air 2012 11" i5 | MacBook Air 2012 11" i7 |
|---|
| | CPU Temp | Fan Speed | CPU Temp | Fan Speed |
|---|
| 0:15 | 69 degrees | 2001rpm | 85degrees | 2002rpm |
|---|
| 5:00 | 72 degrees | 1999rpm | 90degrees | 2240rpm |
|---|
| 10:00 | 74 degrees | 1995rpm | 88degrees | 3000rpm |
|---|
| 15:00 | 78degrees | 1998rpm | 84degrees | 3748rpm |
|---|
| 20:00 | 76degrees | 2085rpm | 81degrees | 4285rpm |
|---|
| 25:00 | 76degrees | 2441rpm | 77degrees | 4694rpm |
|---|
| 30:00 | 75degrees | 2538rpm | 78degrees | 4786rpm |
|---|
| 35:00 | 74degrees | 2573rpm | 77degrees | 4663rpm |
|---|
| 37:52 | --- | --- | finished pass 1 |
|---|
| 40:00 | --- | --- | --- | --- |
|---|
| 43:17 | --- | --- | iPhoto Library Loaded |
|---|
| 45:00 | 73degrees | 3011 | --- | --- |
|---|
| 45:33 | finished pass 1 | --- | --- |
|---|
| 51:47 | iPhoto Library Loaded | --- | --- |
|---|
Conclusion:
This appeared to be a single cpu process for an extended period. The i7 was able to run at full capacity as the fans never reached maximum operating speed. From the final numbers, it seems the i7 has a very significant speed boost over the i5 with single CPU operations.
| MacBook Air 2012 11" i5 | MacBook Air 2012 11" i7 |
|---|
| Final Time | % slower than i7 | Final Time | % faster than i5 |
|---|
| 51:47 | 19% slower | 43:17 | 16.4% faster |
|---|
Part2 - Handbrake Encoding
To perform the hand brake encoding, I updated Handbrake to the latest version and opened the raw DVD source residing on the desktop. By putting the DVD source on the SSD we eliminate the slow IO of an external DVD drive and maximize CPU by feeding it raw DVD as fast As the SSD can provide it. Similarly to avoid I/O bottle necks, hand brake is configured to save the encoded DVD movie on the desktop as well.
| | MacBook Air 2012 11" i5 | MacBook Air 2012 11" i7 |
|---|
| | CPU Temp | Fan Speed | CPU Temp | Fan Speed |
|---|
| 2:35 | 90 degrees | 2033rpm | 102degrees | 4425rpm |
|---|
| 3:45 | 94 degrees | 2408rpm | 100degrees | 5655rpm |
|---|
| 5:14 | 92 degrees | 2906rpm | 97degrees | 6497rpm |
|---|
| 9:00 | 88degrees | 3962rpm | 97degrees | 6496rpm |
|---|
| 11:19 | 87degrees | 4499rpm | 98degrees | 6496rpm |
|---|
| 13:01 | --- | --- | 82degrees | 6497rpm |
|---|
| 15:00 | 84degrees | 5136rpm | 97degrees | 6502rpm |
|---|
| 17:14 | 82degrees | 5332rpm | 98degrees | 6498rpm |
|---|
| 19:01 | 80degrees | 5580rpm | 99degrees | 6500rpm |
|---|
| 23:41 | --- | --- | finished | |
|---|
| 29:28 | finished | | --- | --- |
|---|
Conclusion:
Unlike the previous test, this used all available cpus and hyper threads available. The i7 did top at 99 degrees 6500rpm fan speed and remained there for the majority of the test. From the final numbers, it seems the i7 has a very significant speed boost over the i5.
| MacBook Air 2012 11" i5 | MacBook Air 2012 11" i7 |
|---|
| Final Time | % slower than i7 | Final Time | % faster than i5 |
|---|
| 29:28 | 19.6% slower | 23:41 | 24.4% faster |
|---|
This is an amazing speed increase and for anyone considering using this machine as a main computer and do not mind the spool up the fans during heavy use, the i7 seems to be the way to go.
Part3 - Battery Test Real World Usage
For the battery test, I charged both MacBooks to 100% and left them plugged in for an additional 30 minutes for any left over trickle charge. I setup a web page which does not cache and auto reloads the USAToday web site every 10 seconds. In addition to this, I launched Windows in a VMWare session configured to use 3gigs (of the total 8gb the machine has) and additionally configure Windows so it does not go to sleep. By leaving windows running like this, the CPU's were gradually above 5-10% of use as shown in the video. This along with the browser refreshing should resemble a typical day of usage. Since I started the test around 3AM, I configured the MacBooks to go to sleep after 3 hours. Upon waking up, I can check the battery meter and compare them among both machines.
Conclusion:
As expected the i7 consumed a bit more power than the i5 under normal loads. The consumption however is less significant, comparatively speaking to the gains in CPU from the above previous test. This can be interpreted as a more efficient CPU under normal operating conditions. In simple terms, it can do more work with less power -- so long as you are not a power user who pushes the computer to high limits often. The results after opening the MacBooks the following morning:
| MacBook Air 2012 11" i5 | MacBook Air 2012 11" i7 |
|---|
| % Battery Left | | % Battery Left | |
|---|
| 38% | | 29% | |
|---|
Normalized over the entire battery, you are looking at a difference of about 12%. Meaning, should the MacBooks stayed on, the i7 would have shut off on it's while the i5 would still have approximately 12% charge left.
Part4 - HandBrake Test while docked in clamshell mode
Since I plan to use my MacBook Air primarily in clamshell mode while at home or office, it's performance in this mode is very important to me. I was VERY surprised with the performance findings in this mode. I did anticipate a higher cpu temperature due to reduced airflow, however I found other surprises too.
Unconvinced, I decided to cross check if the i5 also suffers from this. My initial guess is no, because it has better thermal characteristics than the i7. Indeed, that was the case. Below is the same handbrake video being performed by the i5 in clam shell mode.
Conclusion:
Based on my clam shell mode test, it's clear the CPU never went above 100 degrees and instead the CPU's processing power is reduced to control temperature. In clam shell mode it does indeed not get enough circulation for cooling purposes and instead of the machine overheating or shutting down altogether like the iPad in sunlight, it simply reduces the processing power of the CPU. in this case, it was reduced significantly enough where it was roughly 25% slower than the i5 in open mode sitting on a desk.
Overall Conclusion
While the speed increases make the i7 shine when compared to the i5 model, these bursts of speed are most likely not sustainable unless you are in a properly cooled environment and working in the typical open mode. If you plan to use MacBook in clam shell mode, then most definitely the MacBook Air 11" i5 model is way to go for it's superior thermal properties. If on the other hand you have small bursts of power needs, the i7 will give you a good bang for the buck.
|