Re: Note to Chuck Crayne


Frank Kotler wrote:
> True. Caused me to make an interesting observation, though... If *you*
> optimize strlen to shave one cycle off it, and you distribute your
> library to 1000 users, and they each write a program that uses strlen
> 1000 times, and distribute it to 1000 end-users, and they each run it
> 1000 times... that's a hell of a lot of cycles!

But that is spread-out over a bunch of machines and a bunch of time --
how much time is being saved compared to how much time all those
machines spend being idle? Under what conditions are you likely to be
calling a STRLEN function 1000 times in a row?

> As usual, "what are you going to do with it" determines what's "good" or
> "worthwhile".

Indeed.

> There must be "even worse" in common usage. As you know, I like "open
> sauce" software, so if I felt like plowing through the C source, I cou;d
> find a real gem for us to optimize. When I click on the little
> hieroglyph to "sort by thread" instead of "sort by date", it takes - by
> wall clock - approximately a minute and fifteen seconds to complete.
> What kind of a sort algo does *that*???

Perhaps that isn't an algo problem but a program design problem? Why
is the program waitting for the user to click the glyph {the 'qoute
balloon' in Thunderbird I presume?} to run a sort algo to re-order the
messages? A better approach would be to keep a running index table for
every column the user can sort by and every index table should be
updated every time Thunderbird recieves an email/post...this way, the
click on the glyph merrly selects which index table to use when picking
what message headings to show in the window -- no need to run no
freak'n algo.

>
> "Optimizing strlen" is not going to solve this type of problem, but
> getting rid of the "it doesn't matter" attitude might...

This attitude change also goes for the over-all program design... and
in most cases, is where it is more important than at the algo level.

Nathan.

.