Re: One more "strlen" - was: Note to Chuck Crayne

Frank Kotler wrote:
> best to store it?), so we have to imagine we've got a lot of strings
> being thrown at us. Then, why do we need the length? Presumably, we've
> got to do some "processing" of these strings... would it make sense to
> "interleave" the end-of-string test with other processing, rather than
> calculate it separately? Only if we can rule out the "don't do it at
> all" option do we need to think about a fast strlen. Still, we might
> need to do it sometime...

Yeah, perhaps programmers should consider spawning "threads" more
often... if it results in a better user experience.

> > 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.
> That sounds like it would work well. I suppose we could argue that all
> that indexing is "wasted" if the user *doesn't* use it.

Yeah, I think Thunderbird has something like 16 possible columns and
only about 5 are selected (default) for viewing -- may not want to
processor "wasting" time keeping these indexed when it could be
fetching the next message...

> Even if we wait
> for "on demand" to do our sorting, it ought to go along a little faster
> than that.

Are you suggesting that the Thunderbird coders depended too much on
pre-built "black box" libraries, O-O frameworks, wrappers and other
High-Level crutches? Naa, surely not! ;-)

> Disclaimer: I'm complaining about software that is *not* the latest
> version, running on hardware that's a little underpowered for the task.

Yeah, it seems that everyone programs with the assumption that target
machine will be at least a 2 GHz variety (with 256 MB work area, high
HD transfer speed, and fast graphics subsystem), but there is still a
large "installed base" of older machines out there that people are
acquiring software for. In fact, unless you pick up a DOOM 3 box, a
good bit of the packages at Wal-Mart require only a 500 MHz machine --
that tells me that blindingly fast machines are not the norm.

> that, I'm quite sure. I mentioned it only as an example that the "any
> old thing is good enough" rule, if consistantly applied, really *does*
> result in stuff that's "too slow" sometimes.

Yeah, don't start a bad habbit and it won't come back to haunt you