as it turns out, my powerbook can't beat up your powerbook after all.
several
of my beta testers complied with my request, downloaded the benchmark, and
submitted results. it turns out my computers are average (my powerbook)
and
slower than average (the powermac i use for development). however, my
computers do have more than the average amount of ram, and that may well
trump
hard disk access speed. i am not able to google up anything on how macosx
allocates ram for disk buffers, but it stands to reason that more ram
means
bigger disk buffers. the fastest disk access is one that isn't performed
at
all.
but to tell you the truth, i think "speed" is about 85 percent perception,
and
has very little to do with how quickly stuff actually happens. for
example,
the perception that my mark-all-read function is slow. the way it
currently
works is: a background thread marks all messages read, then informs the
main
gui thread, which re-reads the group, finds there's nothing to display,
and
therefore leaves the headers view empty. this works in the general case
for
all forms of mark-read and mark-unread, such as marking a thread read
instead
of all messages, marking selected messages, and so on. but 85 percent of
the
time, the user is marking all messages read. so i could have added
optimized
code for just that particular case, and done things differently. rather
than
marking-read first, which is the slow part, and updating the headers view
later, i could just remove all contents from the headers view and set the
unread count for that group in the storage view to zero. zing! done!
instantly! then, the background thread could go about its business of
silently and s-l-o-w-l-y doing the actual job of marking the messages read
in
the group, without displaying any progress at all. going slowly would
keep
the hard disk from making any tell-tale grinding noises. remember, we're
trying to give the user the illusion that the process is already finished,
long ago. so the entire operation in reality would take several times
LONGER
than it did before, but from the user's vantage point, it finished
instantly.
it might sound like i am being flippant here, or making fun of people who
value perceptions over reality, but i'm actually not. perceptions are
indeed
more im****tant than reality. and i am seriously considering pulling
little
tricks like this in the future.
there are, of course, problems. as long as you don't try to access the
group
that was just marked-all-read for awhile, the illusion will hold. but if
you
should try to go look at that group before the background thread is
finished,
you'll discover the emperor has no clothes. you won't be able to view it,
because the background thread has the cache database for that group
locked,
while it marks all messages read. you have to pay now, or pay later.
i'm trying to find op****tunities where you can "pay later." one of my
greatest strengths as a programmer is writing multi-threaded code that
does
not crash or trip over its own feet. it's a rare skill, because most
operating systems treat multi-threading as a bad joke, bolted-on,
under-do***ented, de-emphasized, and not well integrated with the
platform's
other features. many mac apps have a serious "beachball problem," where
they
put up the beachball cursor that means they are not responding to gui
events,
because they are performing some long-winded operation in the main thread
that
really should have been farmed out to a background thread. perhaps the
author
actually tried that, but made the usual beginner's mistakes, and ended up
with
a bunch of nasty bugs that were very difficult to reproduce or fix. so he
ripped out the threading code and settled for the lesser evil,
beachballing.
too bad more of those guys didn't spend a year or two in beos, like i did.
it's the only operating system i've used so far that makes multi-threading
as
easy as possible. it still wasn't actually "easy," but at least the os
didn't
actively discourage you. in fact, they gave you no choice: every beos
window
runs in its own thread, so your gui app WILL be multi-threaded, whether
you
like it or not.
|
