From: Keith Gaughan <kmgaughan@...>
Date: 2006-07-27T11:17:44+09:00
Subject: Re: For performance, write it in C

On Thu, Jul 27, 2006 at 10:50:32AM +0900, Chad Perrin wrote:

> On Thu, Jul 27, 2006 at 10:35:52AM +0900, Keith Gaughan wrote:
> 
> > Actually, the part that counts, calculation engine, comes in two
> > varieties: a slow but provably correct version, and a fast, highly
> > optimised version, a significant portion of which is written _assembly
> > language_. MS use a battery of regression tests to ensure that the fast
> > one always gives the same results as the slow one.

> That might be the "part that counts" (nice pun) for calculation, but
> it's not the only part that counts.

As far as Excel goes, it is. It's the single biggest time sink in the
application.

> Interface rendering, interactive
> operations, and so on are also fairly important performance-wise

...most of which is down to Windows itself, not Excel. Excel's
contribution to that lag isn't, I believe, all that great. So in this
regard, your complaint is more to do with GDI and so on than with Excel
itself.

> least to the user.  In fact, calculation waits can be easier to overlook
> as a user than waits for the application to catch up when you click on a
> button.

Two point:

 1. As far as I know, Excel runs its interface on one thread and the
    calculation engine on another. This helps give the apprearance of
    Excel being snappier than it actually is: you're able to work on the
    spreadsheet while it's recalculating cells.

 2. On simple spreadsheets, the lag isn't noticible. But Excel is
    designed to be able to handle big spreadsheets well. That's why so
    much work is put into the calculation engine rather than having an
    interface which is completely fat free: in time critical applications,
    it's the calculation engine that really matters.

I use Excel a lot, and have for a few years now. Grudgingly, mind you,
because I dislike having to deal with spreadsheets. But as far as MS
applications go, I think your accusations of slowness and bloat are a
little off the mark and better targeted towards its fellow MS Office
software.

Where Excel *does* fall down in turns of speed is disc I/O. There it can
be atrociously slow.

> On the other hand, if we were specifically referring to things like
> column calculation speed (of which I wasn't strictly aware), then your
> point is made.

Recalculating a spreadsheet is something more that just calculating
columns. Excel itself is a Turing-complete dataflow machine. Getting
something like that which is both correct *and* fast is hard.

K.

-- 
Keith Gaughan - kmgaughan@eircom.net - http://talideon.com/