Acer C7 Chromebook Review

As mentioned earlier, if this was a $329 Windows 8 notebook, it would be considered severely compromised, especially compared to notebooks priced closer to $500. When we heard about the presence of a mechanical disk, we wondered what sort of an impact this would have on performance. The embedded SSDs we're used to in Chromebooks don't exactly offer breakneck speeds, but we've shown time and again that there is often a performance difference of several orders of magnitude between the fastest mechanical drives and the slowest modern SSDs. Thankfully, we're never lacking in NAND-based storage, so we swapped in an idle 120GB OCZ Agility 3. Most of our suite of web tests can live comfortably in RAM, and with nothing but Chrome as our platform the user really shouldn't ever experience how slow the mechanical drive is really, except in boot times.

The only difference of statistical significance is the WebGL Aquarium test. Like all operating system's, Chrome OS relies on a page file on local storage for those occasions where memory is insufficient for the active tasks. Typically you would see inactive bits shuttled into the page file and then recalled to memory when RAM is available and those particular bits are necessary. We run our test suites with no other programs or browser instances running, so anything that spills over to local storage is the result of that 2GB RAM limitation. The WebGL Aquarium test is bulky enough that it spills into the cache and the result is a huge increase in performance when an SSD is used. How does this difference manifest in the real world? Most likely users might perceive some speed increase when swapping between tabs, and better boot times. So if the HDD doesn't do much for performance, what about the RAM? The C7 comes with a scant 2GB of memory, on a single SO-DIMM; that's well below what we'd recommend for even the most budget notebook experience in Windows or OS X, but perhaps enough for the small footprint of Chrome OS. Let’s find out if it’s enough by swapping the single SO-DIMM for a pair totaling 4GB.

Acer C7 with back cover removed, 2x2GB SO-DIMM installed

The data is quite reminiscent of the deltas we saw after swapping in the SSD, and that validates the suspicion that even in our test environment, 2GB of RAM can be overwhelmed quickly and the device can end up hitting local storage more than we'd like. By raising memory to 4GB we still see negligible performance changes in the majority of tests, but a huge increase in the Aquarium test.

There's more to it than synthetics, though. We're used to having an excess of browser tabs and windows open at once here at AnandTech. My workflow generally involves at least three windows, and several tabs in each, and I may hop between many tabs in quick succession to look through research or move between GMail and Google Reader or Twitter. While working with the stock configuration it wasn't uncommon to have tabs I had just moved away from refresh when I moved back to them. At first I wondered if this was an expected response, an effort by Chrome to ensure that the most current content was presented to the user, but this strategy seemed foolish in too many instances to make it logical. Take for instance shopping; if you're working on a computer configuration, it would be a nuisance to have to repeat your selections whenever you switch tabs, triggering a refresh. What became clear once I'd switched to the 4GB configuration was that the behavior was really related to memory capacity. When a tab is moved from memory to the local disk, a flag is tripped telling Chrome to refresh the content when the user returns to it. With an appropriate amount of memory the only tabs that would end up in local storage would be ones that hadn't been accessed for quite a while. Here, though, the tabs end up getting refreshed every time they are accessed. From a user perspective it was night and day; one configuration could hardly handle a half dozen tabs, the other seemed unfazed by my regular workflow.

So, more memory and better storage are all it takes to juice up the C7, right? Not quite. The single biggest performance improvement required just a few clicks. Just as Google is constantly pushing updates to the Chrome browser, Chrome OS is frequently updated and several build channels are available. We did all of our testing on the Stable channel, which sees fewer updates than either the Beta or the Unstable (Dev) channels. Performance and stability tweaks will be the most common aims for updated dev builds, though occasionally features may be added to the Dev channel and slowly make their way to the Stable builds. So, how does the Dev build compare to Stable?

Often, when software is tweaked for performance in one area, it's at the expense of performance in others. Here you see some marginal improvements in JavaScript performance, and some enormous improvements in tests that leverage the GPU. The increase in the HTML5 Fishbowl test is enormous and likely indicates that the Stable build doesn't feature GPU acceleration for the HTML5 techniques being used. A loss in performance in the Bubbles test could indicate that other changes to the JavaScript engine limited performance in some elements. When you look at the WebGL tests, the results show a clear improvement in GPU performance, despite the negligible drop in performance in the Solar System test.

In addition, the Dev channel features options for extending the OS's desktop onto a second display, though I'm not sure the utility, except for those that often need to see two browser windows side by side and are hampered by the limited screen space. So are their any deficits to using the Dev build? During testing the Dev build featured no major instability and had no lock-ups or other hinky behavior. So, ultimately, my only complaint with switching to the Dev channel is that returning to the stable channel requires a full recovery.