Once upon a time, it was a requirement. My first computer had 1K and programmed in BASIC.

I've noticed my feelings toward disk space is out of date, in that I've never had enough and now in recient times it's far more than enough. I mused that it must be like growing up during the great depression: you get a certian mind set and it prevails your whole concept of the subject.

So, I suppose the same might be true about machine efficiency.

—John

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.

---

If the information in this post is inaccurate, or just plain wrong, don't just downvote - please post explaining what's wrong.
That way everyone learns.

 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

Well said.

There is a time and place for everything, and no one language is suitable for every problem. And, as you have already pointed out, ease of development and future maintenance are also factors to look at before choosing a language.

I do also want to point out, however, that people do tend to see the world through their favorite colored glasses. If I see a problem, the first programming tool I look to is Perl. Which may prevent me from properly seeing a more efficient solution. Keep your options open as much as you can and things will work out just fine. IMHO, of course.

I couldn't agree more. So IMHO too :)

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason - including blind stupidity.
-- William A. Wulf, A Case Against the GOTO

Makeshifts last the longest.

However, certain long lived, heavy duty server type programs certainly are much better off in a language like C. the OS, system libraries, servers like bind and apache... These systems certainly do benefit greatly from being programmed in C.

Otherwise, rapid development in perl can save a lot of time and headaches (if the syntax doesn't kill ya :P ) and then a bit of memory profiling can show you the areas that get run the most and either need to be tightened up or programmed in a lower level language.

--hsm