A healthy appreciation of resources is a good thing IMHO.

The system I work with is hellishly ignorant of the resources (disk and CPU) available to it and very inefficient because of it.

We've got several Tb of disk, but waiting for huge files to be written to disk takes an age - I wish some people at least try to keep things sensible.
We do actually run out of disk space - this is bad, and shouldn't happen.

I think it might depend on each programmer - some people automatically produce neat/beautiful/efficient solutions out of the box, others just seem to say "what the hell, there's loads of space!".

Things still have to work and scale.

Before, on the older machines, you wouldn't be able to compile poor code, now the problems are deferred until the volume testing or production phases if someone doesn't think about these things carefully.

Cheers.

BazB.

 I agree that there's an enormous difference between the size and simplicity of some peoples code - partly this is due to skill, practise and ability.

 Sometimes it's background too.

 I started programming in BASIC around 15 years ago on a ZX Spectrum, from this I moved on to Z80 machine code, then onto x86 machine code.

 For a very long time I was the producer of prematurely optimized code regardless of the implementation language. There would be little tiny loops of functionality optimized for speed, or size, scattered throught the code - things would be unrolled for performance, and generally everything was a pain to modify.

 Then after reading 'Code Complete', and a few other related books, I achieved some enlightenment. Since then I've been mostly restrained; only optimizing the code which measurably needs it.

 When I get bored I'll write a version of life in 80 bytes of x86 assembly; that usually works it out of my system, failing that I'll decompile a random binary, and play around with it's internals..

 Optimization for me is a very introverted activity which is immensley attractive. At times it's enjoyable, at times it's painful, but I nearly always learn something new, and I usually enjoy the experience.

 For the average programmer optimization doesn't have a place in 99% of the code they'll write. (This is both a good thing, and a bad thing).

 Laziness, Hubris, and Simplicity are indeed the way to code. Optimize only when you need to, and only then after thinking of algorithmic changes.

Steve
---
steve.org.uk

I do wonder why programmers or wannabe programmers get so hooked on speed and ram.
Once upon a time, it was a requirement.

Still is, in some places. If you have to process a hundred thousand records in one minute (to meet the client's demands for real-time reporting -- yes, I've been there and done that), program speed matters a hell of a lot more than programmer speed. As usual, it's a matter of recognising what problem you're solving, then picking the right tool for the job.

--
F o x t r o t U n i f o r m
Found a typo in this node? /msg me
The hell with paco, vote for Erudil!

It's not completely out of date. We do, after all, have limited RAM, HD and CPU to execute our programs. I could probably implement something that is very inefficient very easily. We want to pay attention to the speed, but we don't want to dwell on it (to the point of micro-optimization) or consider it the final word in language merit.

I could write a script that slurps things into a linear array and do a painful linear search every time I want to see if an element exists. Or I could use a hash to do the same thing in much less time...

Limits: Well, the engraving I did on another thread of TheDamian's code took 8 hours of CPU time on a 1.2 GHz processor. That would have been a rediculous amount of CPU usage and RAM just a few years ago.

Back when I first did ray-tracing, I was using a 80286 with no floating point hardware! One time somewhere between that at the '486SX days I wondered about doing a hand-coded machine language version. The response from the group was that it was a waste of time; effort would be better spent on algorithm improvements than on non-portable and probably not maintainable issues.

In my real work, I feel that using an O(n²) algorithm is "wrong" if you can do it n log(n). That is, don't go out of your way to make it super efficient, but don't do something stupid either.

As for the ray-tracing, I think it was so slow because the objects generated from truetype font extrusions are not set up with simple bounding boxes. If I expanded that project, I would look at putting simple boxes around each line of text to early-out a non-intersection.

But it won't stop me from wishing for a faster CPU, or wishing that the program were designed with efficiency in mind in the first place, with respect to the data structures used.

—John