Progress is Non-Linear

John Gordon:

Gordon's Notes: Progress is non-linear: Palm vs. iPhone Address Book: My iPhone Address book, with about 400 entries, is pretty darned slow.... The Address Book is very slow to launch (4 secs on my phone), but Google Mobile search also searches the Address Book -- and it's fast.... My Palm address book, with about 600 entries, launches instantly. There's no perceptible delay. Time to select an address on the Palm? Maybe 1-2 sec. On the iPhone? Maybe 6-7 seconds. (Faster if you use Google Mobile.) The iPhone has, of course, at least fifty times the processor speed and more than 1,600 times the memory capacity of the original Palm.

The Palm had essentially instantaneous responsiveness from day one. It was one of the design goals of the original team. The Palm was to have instant on, no user waiting for a system response, and no crashes. Incredibly, the original Palm team met those goals. Later... well, that's a sadder story.

Apple will one day fix the iPhone Address Book problems. Heck, Google Mobile already has. It is a good example, however, of the random walk aspect of progress. The iPhone does a lot that the Palm never could, but the original Palm did a lot of things well that the modern iPhone does poorly or not at all. Technological progress is squirrelly.

Comments

[David Lloyd-Jones]

.


Reminds me of a story: Bill Gates a few years ago is wandering through his house, then under construction, and he falls into conversation with an electrician who is installing his wonderful wall panels.

They get around to computers, and it turns out the electrician has never used one, so Bill shows him one. Electrician is puzzled by the start-up time. What's all this "boot" stuff about? Why can't you switch is on, like you do with an electric light?

Why indeed? Seems to me that somebody ought to be selling a commuter with its OS in CMOS. Maybe a little difficult to do with a hog like Windows, but there are several Linuces (Linuxen?) that would fit easily...

[Alex Tolley]

The iPhone is very slow, both to boot up and to do certain tasks. As a S/W engineer, it is not clear to me why this should be so. I mean, 4 seconds to launch and load 600 database records? Of course they could load the first 25, then load more as you scroll down to view more.

[MobiusKlein]

My first guess would be that all the fancy animation on the iPhone is getting in the way. Some iterative process changes some bit that is related to the display, and triggers some refresh, which ends up being a no-op.

Cycles wasted on visual nothings, and the next search goes.

Don't blame the iPhone per-se. Blame the programmer and QA for making bad code and not load testing. (They would likely blame management for rushing out the app too early, who will blame the programmers for not having realistic time estimates...)

[Dave Roberts]

From a recent comparison of a 1986 Mac Plus to a 2007 Dual Core AMD Processor

Check out the results! For the functions that people use most often, the 1986 vintage Mac Plus beats the 2007 AMD Athlon 64 X2 4800+: 9 tests to 8! Out of the 17 tests, the antique Mac won 53% of the time! Including a jaw-dropping 52 second whipping of the AMD from the time the Power button is pushed to the time the Desktop is up and useable.

http://hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

[omeros]

"any notion of human progress is negated by the existence of the iliad."
-- roberto calasso, marriage of cadmus of harmony

[tWB]

Of course, when a big chunk of your OS code is embedded in the firmware (as in the old Macs), bootup *is* quite a bit faster. The downside: your code has to fit in the firmware.

As for the Address Book issue, the problem is almost certainly not in search time (it uses a SQLite database under the hood). NSTableView (or whatever the cool kids are using in the API) is probably the culprit here -- table controls of any complexity can be performance killers in any high-level rendering toolkit.

[jerry]

"Technological progress is squirrelly."

Two reasons: "Not invented here" and hubris: "if they could do it, we can do it to" where "they" was hundreds of people over years testing and in the market place and "we" is you, me, and the guy down the hall when we're not involved in MMORPGs.

I worked at a place that was trying to create a very portable, very distributed, "highly available" operating system. They needed a distributed lock cluster. So did any of these relatively bright kids look into what was free and GPL'd in the Linux High Availability Project? Had any of them ever heard of VAX/VMS Distributed Clusters and the work that went into them to get them right?

Andrew Weil says we need to look more to the placebo effect. It seems to be magic and it's highly effective. But most folks disdain placebos.

Smart engineers know where to steal and borrow. Most of us though will disparage that which is not invented here.

(MK: Management IS to blame, for having no technical clue as to what is capable and what they are offering, for not giving a crap to quality beyond product launch and figuring only the geeks will care, and for not demanding higher quality from the developers, and no, conforming to CMMI 3-5 does not mean you have a quality product, it just means you have a bloated process.)

[omeros]

also, the iPhone system software is a stripped down version of the standard mac os, built on the darwin unix kernel. so it's not just the flashy gui, but a full blown machine. i imagine this makes it easier for apple and other software developers to create apps, port them from other platforms and maintain compatibility with syncing, network standards, etc. (since mac is doing this anyway for their mac OS.) so instead of using palm's strategy of building an OS/firmware optimized for a specific machine, which runs fast, but later turns out to have big problems with scalability/compatibility, apple is taking their mac OS and fitting it on the smallest machine it will function.

[piotr]

Mobius Klein probably describes a true reason.

The problem is that the hardware became so efficient that software designers think that efficiency in algorithm is unnecessary. To a degree, it is, but once you pile up enough of inefficiencies, it shows.

Current software evolution is firmly directed toward the bloat. Bloated code, bloated programming languages, bloated data formats, etc.

[monopole]

"The iPhone does a lot that the Palm never could..."

Actually a Palm T|X with a bluetooth link arguably beats the iPhone like a readheaded stepchild in many regards. Upgrading to Graffiti 1 provides a superior input method, with bluetooth keyboard support providing an additional superior interface. The display is nearly identical to that of the iPhone and installation of the TCMP package provides excellent multimedia playback. The PIM and ToDo applications are readily superior as well. The software base is vastly superior as well. For example I have several excellent astronomy packages which are capable of controlling my telescope gimbal and even astro cameras.

The iPhone is much more about hype and appearance than superior technology. That and the capacity to convince customers that the failings of the iPhone are their fault.

Sadly I no longer use my T|X due to it's poor build quality. I've transitioned to a Nokia 800 internet tablet a full out Debian Linux box in a PDA, including remarkably good browser support and stellar multimedia. I do still run the Palm OS linux stack on the n800

[theo]

"any notion of human progress is negated by the existence of the iliad"

Have to say, as a 1st generation device, I'm pretty impressed with the iLiad. You meant the one from iRex/Philips, right?

[MobiusKlein]

I was likely wrong - but only putting a wild assed guess out. (At least for the proximal cause.) The root cause is that Software Is Hard. And bigger systems have more code, and more code is harder.

Ok, gotta get back to pruning memory leaks and cutting bloat.

[Chris Brown]

I am completely satisfied with the performance and reliability of my feature packed Sony Ericsson 91i smart phone.

[Dave Empey]

Just to pick a nit, the problem here would seem to be that progress is not even monotonically increasing, never mind linear.