Numbers ’13 Performance
Despite fewer features and a newer codebase, Numbers has always seemed slower to me than Microsoft Excel. With iWork ’13 backported from iOS to Mac, I expected to see some performance improvements. After all, iOS devices have less RAM and slower processors. In theory, iWork’s new binary file format should also be smaller and faster than XML.
Here are some measurements that I made on a 2012 MacBook Pro using a 10.5 MB CSV file, an export of my FogBugz cases:
| Numbers ’09 | Numbers ’13 | Excel 2011 | OpenOffice 4.0.1 | |
|---|---|---|---|---|
| Open CSV File | 2m10s | 3m25s | 2s | 10s |
| Save Native File | 6s | 2s | 1s | 3s |
| Open Native File | 7s | 10s | 2s | 6s |
| Open Numbers ’09 File | 7s | 16s | N/A | N/A |
| Native File Size | 2.6 MB | 15.5 MB | 3.7 MB | 2.2 MB |
| Unzipped Size | 62 MB | 16.4 MB | 22.4 MB | 57.4 MB |
For opening my file, Numbers was always way slower than Excel. The new version of Numbers is even slower.
The new Numbers file format is much faster than the old one at saving, but it’s slower at opening. Excel is much faster than either.
Numbers ’13 takes more than twice as long as Numbers ’09 to read files in the old format.
The old Numbers file format was actually more compact than Excel’s. The new format is nearly 6 times the size of the old format.
On the other hand, the uncompressed Numbers ’13 format is more compact than Excel’s format and much smaller than the old format. Presumably, this allows it to use much less RAM.
Update (2013-10-29): I’ve added results from OpenOffice, a C++/Java app that uses a compressed XML document format.
9 Comments RSS · Twitter
I could live with slowness when opening files, but what's inexcusable is that Numbers becomes unusable for larger tables. When tables become large enough (in my experience, a few thousand entries does the job), rendering graphs becomes effectively impossible. Meanwhile, the same tables work fine in Excel.
Large tables, and especially formulas dependent on whole columns of those tables were very slow with the old Numbers, and are still somewhat slow in my experience (especially when adding rows). I learned with the old Numbers however that if you have fixed columns on the left it's much worse (probably because it wants to use those values as row identifiers), so I don't use them for most tables nowadays.
I really don't care how much time it takes to open the file. Editing the file without a one- or two-second delay for recalculating things after each change is so much more important.
I think optimizing for Save makes sense in a world w/ autosave. Document open happens once per editing session, whereas autosave happens every ~30s while you're modifying the document. Even if you put it on a separate thread (which I know iWork 09 couldn't do, not sure about iWork 13), it still consumes additional resources if it's an expensive operation.
[…] versions of the iWork apps change the file formats again, but it’s not as drastic a change as last year. Numbers 3.2.2 created a package folder with some metadata and a ZIP archive containing the .iwa […]
[…] reports some big performance improvements. My 2013 test of opening a CSV file now takes 44s in Numbers 3.6.1 (down from 3m25s) vs. 3s (up from 2s) for […]
