>I was not opposing efficiency, just saying I don't think in general it is important as it used to be when memory and hard drive space truly were constraints.

OTOH, I think the programmers should learn a few tricks in that direction. It's one thing for us old foxen to know when something may take a little longer, but in the grand scheme of things won't matter (IOW, I may take two days to save 300ms a day to 130 customers, which will turn into a great overall saving of time after a number of years, by which time all involved - code, hardware, OS, people - would be retired anyway). It's quite another to grow up as a programmer having this attitude that speed doesn't matter and the optimization tricks, or at least the speed troubleshooting techniques, are not important.

I've met several cases where the code written by my predecessors on the project was easily sped up by a factor of 20 to 40 - like using nested scan/endscans to traverse a tree, instead of doing a select on child records (and if _tally=0, ah, it's an endnode), and then storing the results of that in a rip field by which you'd index it and then you have your tree in the order you want. Or, another one, when having one huge table joined with six others, select from that table alone and then join the resulting cursor - factor of about 15.

I think that even Windowses are mostly written that way, which may be why their general speed didn't change much in the last 20 years, despite the hardware acceleration.