From: Chad Perrin <perrin@...>
Date: 2006-07-27T11:38:34+09:00
Subject: Re: For performance, write it in C

On Thu, Jul 27, 2006 at 11:17:44AM +0900, Keith Gaughan wrote:
> On Thu, Jul 27, 2006 at 10:50:32AM +0900, Chad Perrin wrote:
> 
> > 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.

. . .
I'll put it this way: it's not the only part that counts for me, and for
other spreadsheet users with whom I've discussed Excel in the past.


> 
> > 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.

Excel doesn't run so well on Linux, so I'll just leave that lying where
it is.


> 
> > 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.

. . . and yet, the interface being fat-free would be awfully nice.
Instead, it gets fatter with every new version.


> 
> 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.

It's true that other MS Office applications are worse.  That doesn't
make Excel perfect.


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

I certainly won't disagree with that.  Disk access seems to be another
problem -- though it's easier to overlook than some other issues, once a
spreadsheet is loaded and before it needs to be saved again.


> 
> > 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.

I don't particularly see how that contradicts what I said.  I may have
been more flippant in my reference to calculations than you'd like, but
I didn't say anything inaccurate.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
print substr("Just another Perl hacker", 0, -2);