Hacker News Reader

Comment by martey | Hacker News Reader

The processor is the MacBook Air is different (lower voltage, lower clock speed, lower performance). Add in a slower hard drive (only 4200 RPM) and the difference in performance between it and your MacBook Pro is no surprise.

View on HN

Yes. It's the same with every portable device: Customers complain if the thing weighs too much, they complain if the thing runs too slowly, and they complain if the battery life is too short. Unfortunately, since it is nigh-impossible to improve all three of these factors at once without fundamentally improving battery technology [1] -- a glacially slow process compared to Moore's Law -- to build a portable device is to sign up for a torrent of customer complaints.

I'm sure that various aspects of the Air's performance have been deliberately throttled to ensure that its cute little credit-card-thin battery doesn't crap out after half an hour. One thing to try is simply plugging it in. There's no mention here of whether that made a difference.

And Parallels? Geez. How many computers worth of computer does this guy expect to fit in a manila envelope?

[1] You would think that each generation of improved processor designs would improve performance. And it does. But every time processors speed up, our desktop-wielding developers dream up an incredibly fun, more-processor-intensive thing to do with all those new cycles, like render more polygons or playback multiple Flash videos or use IMAP or do real-time JOINs between your friends' friends' Facebooks, and these two factors roughly cancel out.

One word: Fujitsu.

Just bought one of their S6410s. 13-inch screen ultralight with good performance and great battery life. Don't know if the machines are available in the US yet, but the laptop rocks. Small enough you can use it on a plane with the screen fully open, or throw it in a knapsack. Large enough to be my main computer, although I like to browse the web with F11.

My gripe with the Mac is that it's too expensive for what you get. I've never been inclined to put a laptop in a manilla envelope though, so I'd guess I'm not their market. Only problem with Fujitsu is that the company seems actively disinterested in selling their products (took ages to find a local reseller) and the company has literally nothing in the way of Linux support, not even "unofficial" drivers. They also do that awful "backup as a partition" that screws up when you repartition the hard drive to do things like install useful software.

Ubuntu is up and running now though, and it's great.

How would the CPU and disk performance of the MBA compare to a Powerbook G4? That's what I use now.

The CPU will be faster, and the disk will be faster if your PB also has a 48k RPM drive (higher data-density at the same RPM == more bytes read per rotation). Otherwise you'd actually have to look at the transfer and seek rates of the drive

Yah - except you can easily (and cheaply) upgrade the PB to a 72K RPM drive, something not possible with the MBA - given it's 1.8" form factor.

I would suspect, with an upgraded drive, a 1.5Ghz PB would be more responsive opening applications & starting, while the MBA might be able to handle more simultaneous apps running, due to the 2GB ram and faster processor.

I suspect the 4200 RPM drive to be the culprit of most performance woes on the MBA.

Add the Solid State disk though, and from what I hear, compiling code is extremely fast.

Of course, I could never justify the cost of the SSD today.

I didn't go for the SSD and the performance is fine for me.

I should have qualified extremely fast: From what I hear, it can make compiling go faster than the MBP, despite the slower processor, solely because disk reading is so much faster. With a large project and lots of small files, disk access adds up.

On Gentoo, where compiling occurs nearly every time a program is installed, one common method used to speed up compiling is to use the -pipe option to gcc as well as to mount memory onto /var/tmp/portate (the location where files are written before actually being installed). These two measures alone can speed up compile times dramatically, as the disk is never touched in the middle of compiles. Instead, the only time reads occur is as the source is read in, and writes only occur when the final binaries, libraries, and configuration files are installed to their homes on the file system.

If your source files are located contiguously on the hard drive [1] and writes are cached to occur in big blocks, while also using some compile-in-memory techniques like those outlined above, I imagine compile times would not vary much on flash-disk MBAs as compared to those with conventional laptop drives.

[1] This could be accomplished by keeping your project in a compressed file and loopback-mounting it to your project's working directory.

Reply on news.ycombinator.com