

Can modern software be snappy? - edw519
http://blog.micropledge.com/2008/06/snappy-software/

======
tx
The fastest computing experience I had was somewhere around 2001-02 or so, I
had PIII 1Gz with 256MB of RAM and 3MBit DSL connection.

Everything was screaming: every piece of software I ran, every site I visited.
I forgot how "Please wait..." popups looked like.

After that, it's been declining ever since: my software has gotten slower and
slower, and web sites started to bring back dial-up memories from mid-90s.

After switching to Linux I got back most of what I lost, but the web still
feels much slower, even Gmail is giving me "Still working..." strip at the top
on a daily basis and randomly 1-2 squares on google maps remain gray after
initial page load: hard to bitch about free stuff though.

~~~
ROFISH
I personally have found a lot of software to be I/O bound instead of CPU
bound. Specifically hard drives. Try loading up something. Does it wait
forever because the CPU is at 100%? Or is the hard drive light blinking like
nuts?

Our quest for never-ending data seems to slow things down. In the age of
terrabyte hard drives, the only real limitation on program size is the average
broadband connection on most freely downloadable apps. (And it's even worse
for programs that come on a disc!)

There recently was an article about how spellcheck worked with limited
resources. Word might be loading a smallish, compressed English dictionary
back then, but loading uncompressed, unabridged English dictionary today since
there's no real hard drive space constraint.

Never blame a poor, bloated algorithm when the problem is just as likely our
unfettered need for more data.

~~~
tx
I personally have found that most software is idiocy-bound, like creating a
search thread for every key typed in "Quicksearch" box (Vista, with indexing
disabled). Or loading an _entire_ page via 12 AJAX-requests, instead of
serving it all at once, circa 1998. _(and THEN doing a round-trip to the
server only to report back that I shouldn't be putting dashes in my phone
number)_

As for I/O... it's is nothing, I've got plenty of it.

------
ajross
I think some of the meta-point might be a bit strained here. It's true that
there's a _lot_ of bloated software out there. And the example at the top,
Acobat Reader, is one of the worst. It's a dog, and really easy to improve on.
I've never heard of the "Foxit" product, but the poppler-based Evince reader
on my Ubuntu box is similarly "snappy", even on huge documents (scanned-in D&D
sourcebooks, for example -- yes, I'm a geek) where Adobe really crawls.

That said, there's a ton of common GUI software out there that really does
deliver a pretty quick UI experience. Firefox 3 comes to mind as a good
example here (especially given how hard it is to make some web content
"snappy"). Likewise many of the smaller utilities on a modern Linux desktop
are nice and quick.

Basically, the problem is real, but not as widespread as the article posits. A
quick and clean desktop experience on modern hardware is both possible and
available if you're willing to look for it.

But yeah, Acrobat is awful.

------
silentbicycle
BeOS felt _really_ fast, on a 200 mhz computer, several years ago. While the
article's example is of Assembly optimized for performance over
readability/maintainability (and I know people have written entire GUI OSs in
Assembly, e.g. <http://www.menuetos.net/>), I know a clean, maintainable,
responsive OS in a higher-level language is also possible. While I don't
really know the details, I think BeOS had an asynchronous scheduling /
interprocess communication model that was ahead of its time. (I'm not sure if
parallels to Erlang apply.)

And, I second that Acrobat is an unusually bad case, though a pretty commonly
known example. (Few of you probably use the same HR software we do, for
example... Not naming names.)

~~~
michaelneale
From what I remember it was very async in its GUI programming model. You wrote
little event handlers and it took care of the rest.

------
pavelludiq
linux+fluxbox and you are ok. I recommend Fluxbuntu as a good example it beats
xubuntu and its really beautiful(xubuntu is ugly in comparison). Its a very
slim OS i really like it, but i use Kubuntu on my machine, its powerful enough
to handle KDE and i love KDE, but on my other pc i have a fluxbuntu
installation.

------
michaelneale
"The more memory something hogs, the slower it’ll run."

Well it used to be a compromise. You could blow your memory budget to get a
bit of a speedup. But now memory bloat seems to be a cause of sluggishness.

------
Allocator2008
Well, my "specialty" if you could call it that, is QA automation, writing
automated test scripts for the system under test. So I would not consider
myself a "super hacker" by any extent. My current job is writing in 4-Test,
the language of Borland Silk. Before that, I did mainly unit testing
development, some JUnit and XMLUnit, but primarily CPPUnit, the c++ port of
JUnit. In unit testing especially one is cogniscent of what objects are in
play at any given point, since one is writing a class or a method to test a
certain set of objects in the system under test. So I think one becomes very
aware of memory-related issues. I found the hard way writing in CPPUnit that
it is easy to "trash memory" if one isn't careful. That said, I think I prefer
CPPUnit, and C++ generally, for the very reason of the "tough love" it has by
not having an in-built garbage collector like java has. It requires a bit more
of one's attention, but frankly at the end of the day it executed swimmingly.
So, with admittedly my limited perspective from the test automation world, I
would personally have to vote for programming languages and approaches that
force memory, and thereby performance, attention and efficiency. It is
something like linux. Before I learned linux commands by playing around with
cygwin, I much prefered DOS since it was more familiar. But once I learned to
love talking to my computer via the cygwin shell, I never went back! Thus with
writing de-constructors, once you get into the habit of it, you can't ever go
back to not doing it! :-)

