Now that Office for Mac 2011 has been available for a little while, I wanted to talk about some of the work we put into the product that you don’t see but experience every time you use it. You should have noticed by now that Office 2011 is significantly faster than previous versions. There’s a lot of work that went into the product to achieve these performance gains and I thought I’d share some details on what we did and why.
The first thing to ask is “what is performance?” When it comes to software, we’re not talking about interpretive dance. Rather, it’s the perception of how fast the software reacts to user input. Perception is the key factor here – although absolute raw time is a critical part of measuring speed, as I’ll discuss later it’s not the primary target result. We measure performance relative to human expectations. Although it’s handy to measure relative to previous versions of the product and to competitor products, those comparisons simply feed into our overall goal of meeting, or better yet, exceeding user expectations. We don’t tie performance expectations to things like hardware upgrades – a lazy approach to performance is to say “well, it’s fast enough on a new system and everyone is upgrading anyway” – the demands of modern software experiences are continually rising and hardware never quite catches up! We’d rather say “If you want a faster version of Office, buy this new version for $149, not a whole new Mac for +$1000.”
Research has shown that there are several key characterizations of performance – “instantaneous” (0.1 – 0.2 seconds), “immediate” (0.5 – 1 second), and “longer” (2-5 seconds or more). Human beings expect actions to generate results within these groupings. For example, we’re conditioned to expect results from clicking on a button to happen instantly, so things feel slow if a button click doesn’t provide a result within a few tenths of a second. “Longer” response times cover the threshold by which we expect some kind of response – anything longer than a few seconds with no measurable response and we start to imagine that the computer either didn’t register our command or is perhaps in a hung state.
Have you ever clicked on a button, gotten no visible response, clicked on it again, and suddenly had the computer react to two clicks? That’s the “perception” and “expected response” conditioning taking hold in your brain. You may have already seen ways that various parts of the Mac OS or iOS provide visible feedback to indicate or smooth over delays. When you launch an app in OS X, the app’s icon bounces in the dock to indicate that the OS is in the process of launching the app and it may take a little while. In Mobile Mail in iOS, when you delete an email message the screen visibly squishes and drains the message to the trash can. That small animation is a cue to you that the OS is acting on your command; the OS can also do some processing in the background while the animation is occurring, like talk to your email server.
With Office for Mac 2011, we had a team-wide effort dedicated to improving the raw and perceived performance of the suite. We started off defining what we called “KPIs” or Key Performance Indicators. These were a series of procedures such as boot time, Excel recalc time, Word page rendering, Outlook message syncing, where our raw performance and visual cues were mismatched – the operations took longer to complete than the cues successfully communicated and so users had the perception that Office was slow. We focused on reducing the raw amount of time that each key performance scenario took to run and worked out the sort of visuals necessary to communicate the operation status. Our focus was to get the features working correctly and then work on optimizing the code. We didn’t simply guess at what areas were slow or try to optimize for a theoretical scenario; instead we used a variety of tools from the crude accuracy of a handheld stopwatch to detailed performance logs in Apple’s Instruments app to start/stop markers in the code to measure performance over and over and over again throughout the development cycle for Office 2011.
All these investigations pointed to key areas across the suite where we should invest in improvements. We generated ordering files to tell the linker the best order for code so that the OS could load and run boot-time code in a straight line, rather than seeking all over the hard drive to find each function as it was needed. We built a cache for commonly used strings to avoid having to seek through thousands of strings for commonly used controls. We identified code that wasn’t needed in most scenarios and made it load on demand instead of linking to it directly, thereby avoiding having the OS page it in on boot. We added threading to parallelize tasks, and pushed more PowerPoint animations and slide-show rendering to hardware-based operations. We even replaced specific bits of compiled source code with handwritten assembly to eliminate processor stalls due to less-than-optimal code generation from gcc. Some individual changes cut over 2 seconds from launch time, but we tracked things as small as a few tens-of-milliseconds – as we got the big issues fixed each smaller performance optimization made a larger percentage gain in boot speed. Fixing ten issues at 30-40ms each removes a full third of a second of time spent doing an operation and that can make the difference between whether an action feels instantaneous or not!
So, how did we do? Let me show you! Here are two simple videos of Excel 2011 launch and recalc as compared directly to Excel 2008. (Pardon the rather low production quality; I took these with my iPhone this afternoon with the help of Olof, another developer in MacBU.) These tests were run on identical first-generation 17” iMacs with 2GB of RAM and OS X 10.6.5:
We ran lots of profiles ourselves, but for the final release our friends over at MacTech Magazine ran some benchmarks, and I think they pretty clearly demonstrate the across-the-board performance gains. We are excited with the improvements we’ve made in Office 2011. However, we’re not done yet. For 2011 we focused on some of the highest impact areas such as boot but we see performance improvement as a permanent mission for us – we’ll be continuing to invest time and tools into making Office the fastest productivity suite on the Mac as we continue to deliver on our commitment to the platform.
Erik Schwiebert – Senior Development Lead, Microsoft MacBU