Allen Brunson
2005-10-15 01:09:39 UTC
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 important 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 opportunities 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-documented, 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.
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 important 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 opportunities 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-documented, 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.