The Chromebook Pixel Reviewby Jason Inofuentes on May 31, 2013 8:00 AM EST
The Memory Issue
Memory has long been an issue for Chromebooks, but I didn’t understand why until recently. The incredibly high pixel count certainly wasn’t going to help things. To find out how they might cope with this issue, we caught up with Caesar Sengupta, Product Manager at Google for Chrome OS. I've never understood why Chromebooks always come with modest memory on-board. It isn’t a cost issue, certainly; memory is cheap. It's soldered on, and comes in denser packages so it’s not likely a space issue. Google's making a conscious choice to go small with memory. So, how do you cope 4 million pixels and just 4GB RAM? In this case, the first step is to render all pages at 1280 x 800, unless HiDPI assets are available. The final product is upscaled to the full 2560 x 1600, but the memory doesn’t take nearly the punishing you might expect; unless, of course, every site you visit has HiDPI assets.
Then there’s a user behavior problem that has long plagued Chrome OS. Tabs linger and multiply. An untidy user could tax the memory assets of any system with tab after tab of unread longreads and cat GIFs. With memory taxed, the OS will begin shuffling under used bits of data into a swap file on local storage, effectively an extension of system memory stored on your hard drive. Even the fastest SSDs are several orders of magnitude slower than RAM, so switching to a tab whose contents had been pushed to the swap file would briefly yield a blank screen as the content is brought back to system memory. The developers of Chrome OS had a mission: an operating system that lives and breathes entirely within system memory. That means, no swap file. And that means an often frustrating user experience.
That same untidy user could bring a Chromebook to its knees with open tabs, and with no swap file, pages purged from memory are simply refreshed when focus is restored. Not that big of a deal, right? Say those tabs are actually your site’s content management system and dozens of tabs of research. Further, that you’ve just spent an hour putting together a great post, and tabbed away just long enough to verify a bit of research. Switch back to your CMS, the page refreshes, and your great post disappears into the ether. Surely, there's a better alternative. Please?
Android enthusiasts will be familiar with compcache, a method of creating a compressed page file on system memory that can help alleviate memory shortages. Now called zram, this technique fits perfectly within Chrome's philosophy of speed over all other factors. Local storage options vary too much in speed for their speed targets with Chrome, so operating even the page file within memory is a logical step. In practice, zram is better, not great. When a page is purged completely, you get the Chrome BSOD equivalent and an option to reload. This alleviates system slow downs that arose from automatically refreshing each page as you tabbed through them. I haven't noticed any particular slow down that might indicate that a given page's data was being recalled from zram, which could be a good sign. But there's no changing the fact that slicing a piece away from that 4GB for use as a page file isn't nearly as effective as adding another 4GB.