Re: Performance optimization vs satisficing (was Language Oriented Programming)

Responding to JXStern...

<hot button>
Years ago Djikstra wrote a piece for one of the professional rags bewailing code bloat and downgrading performance. (Anyone remember when one could run a spread*** on an Apple II, whose cycle rate was measured in KHz, with 128 Kb of memory and a 700 Kb floppy disk?) At the time I thought he was, once again, ahead of his time. Moore's Law has lulled a lot of the industry into believing that performance problems can be solved by waiting for next month's bigger and better machine. 


Microsoft has been a leading offender here.  The year I graduated
college, IBM mainframe (core, 2 microsecond) memory was a nice, round
one million dollars (that's about $4m in current dollars) per
megabyte, for a 2 MIP 370/168 that might support a hundred TSO and CMS
users on 2741 Selectric and 327x green (or color!) channel-connected
CRTs that cost about 2x what PCs cost.  Girl friend employed there was
assigned to enhance IMS performance running in an average sized 256KB
(kilobyte) partition.  Ah yes, those were the days!

I guess I have a few years on you. B-) My fond memories are of plug boards when changing vacuum tubes was part of a Programmer's job description. I also have fond memories of ka-chunk, ka-chunk, ka-chunk -- using teletype machines with 5-lb piston keys. Those were such character-building experiences that I quit software for a decade until ca '68 when there was high tech stuff like your 3270 terminals (always green then).

IT has been particularly affected because disk access time has not dropped as quickly as CPU cycles/sec have grown so the traditional I/O bottleneck has just gotten worse and software optimization has become an arcane issue for server engines. Got a performance problem? Buy another server. 


Well, yes and no.  Someone always wants more, and the numbers are as
you say, but now typical Wintel networks have terabyte SAN/NAS (RAID)
boxes on gigabit channels, which helps overall thruput, it's not news
by mainframe standards but it's pretty darned fast, pilgrim, long as
you don't mind at least a little latency.  And the processors are just
ridiculously fast, even though Wintel still doesn't grok large degrees
of parallelism and has various difficulties loading (dirt-cheap!) RAM
about 4gb or so.  So yes, the gap between processor and disk may grow,
but the overall power available for commercial apps is huge.  What I
mostly see around town is endlessly sloppy code that gets by because
the hardware is sufficiently fast.

Right. Any improvement in I/O throughput via parallelism, caching, or whatever will just make it less easy to get away with pig code in middleware or on the client side. Similarly, improvements at the middleware level will also push back on client performance. That is, client screwups just become more noticeable.

I suspect the problems you end up fixing to get the first 300% are often the result of developers simply not caring about performance because of that obvious hardware gap. IOW, they look at the hardware gap and naively assume hardware will take care of everything.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.