Fast At Any Speed

One of the major engineering feats associated with shipping Office is making
sure it runs fast enough.  This effort, which we classify under the broad
heading of "performance" includes responsiveness (how quickly a button responds
when you click it), throughput (how fast Excel can recalculate a spreadsheet),
and "perceived" performance (do the fade out of menus seem right?) 
Depending on the program, there might be other issues as well, such as network
throughput and latency issues, document save/load times, graphics rendering
engine speed, etc.

A software legend has somehow arisen that Microsoft waits
until the last release candidate and then tunes up performance at the very end
before the software goes out the door.

Nothing could be further from the truth; good performance needs to be
fundamentally designed and architected into the product--something far too risky
to do at the last minute.  From Beta 1 onward, a large portion of the
resources of Office development are spent making sure that the software is
speedy enough: testing on memory-constrained computers, processor-constrained
computers, terminal services, Run From Network, x64, and all sorts of different
configurations.

From the perspective of the Office 12 new user experience, performance is
critical.  The very visual nature of the Ribbon, with lots of galleries and
Live Preview, lends itself to experimentation.  A key goal of the Ribbon is
that it's easy to poke around to find and use new functionality.  However,
most people will only poke around if the interface is responsive and crisp. 
For example, if it took two seconds to switch between tabs, it might dissuade
you from browsing the Ribbon as readily.  In fact, we've noticed a profound
link between performance and usability; some usability tasks that totally fail
when the interface is laggy and lethargic suddenly do great once the software is
responsive enough.

With the huge number of improvements in Office 12, making sure the software
is responsive is a really critical task.  But it's one that we're totally
committed to, because great performance is one of the fundamental building
blocks of great software experiences.

Comments

• Anonymous
  December 09, 2005
  At what point to Office devs start optimizing their code? I've always read that optimizing early is a mistake because you just don't know where your performance bottlenecks are going to be.
  
  (Now granted, if you're dividing a val64 by a val32 you should probably know enough not to do it in your innermost loop: http://blogs.msdn.com/larryosterman/archive/2005/10/14.aspx ;-)
  
  So if this is happening early, is it happening at design-time, code review time, being uncovered by testers, software analysis tools, etc.?
• Anonymous
  December 09, 2005
  Jensen,
  I always assumed the speed increase (which I rarely notice) was due to the removal of 'debug code'. Kind`a like the difference between the two MSDN CDs "Windows 2000" OEM and "Windows 2000 - Checked Build".
  Is there any truth to my theory?
• Anonymous
  December 09, 2005
  Chris C,
  
  It's not just debug code, I did Perf on Office many years ago and we had to deal with a lot of different issues related to speed (and we did not test on the debug build :). Well before the first beta we were tracking numbers and if something generated a huge slowdown, even a year out from release, it got fixed.
  
  Speed comes from many different places, some that you might find surprising. But there was a real dedication to making Office go faster, even faster then the previous version. We didn't always hit it, but it most places we did. Pref is one of the unsung divisions of Office who work just as hard and as long as the developers and other testers.
  
  Of course no one notices properly done performance tuning. :)
  
• Anonymous
  December 09, 2005
  
  GDI+ is hardware accelerated? How is Office 2006 going to be any faster if you are adding (a lot of) candy and not using hardware acceleration? Besides this, object transparency is off by default on current Office versions for a reason.
  
  A larger working set, many more page faults due to bitmap loads, no hardware acceleration, 32-bit "toolbar" icons, much bigger icons. I could go on like this for a while.
  
  Sure enough, we have a winner here.
  
• Anonymous
  December 09, 2005
  As long as you don't use my broken APIs (they're not broken any more, btw) you should be ok :) And if you use the built-in compiler support for 64bit numbers you'll be golden - the stuff I did was WAY before the compilers got 64bit support.
  
  Btw, everyone builds both checked and free (debug and retail) from the get-go, so it's not that.
  
• Anonymous
  December 09, 2005
  Jensen said:
  > do[es] the fade out of menus seem right?
  
  Here is how to get that right: get rid of it totally!
  
  I hate things that fade in & out. That is the product saying to me: "Hey pal, I'm the product - not you. I'll respond when I feel like it. Just sit tight, don't hassle me, I'll eventually do what you've asked, but only when I'm good and ready."
  
  I say nix all fading! It has no functional benefit, and just makes the user /wait/ for what he has asked for. It's like a control issue, where the boss could easily say "yes", but chooses not to, just to show who the boss /is/.
• Anonymous
  December 10, 2005
  The comment has been removed