Nov 20, 2001, 12:51 PM
Veteran / Moderator (6956 posts)
Nov 20, 2001, 12:51 PM
Post #5 of 10
Views: 3376
>> they use arrays with numbers instead of names; so its a lot of stress to jump from
>> a to b and find all the neccessary lines to change when modyfing the scripts
This is a good and bad thing. It helps performance, but it makes code support a
BEAR to try to maintain.
GT's Links gets away with it, by using a combination of hash/array accesses. This is
partly what the 'position' field is in the database.
But, it's because of the use of 'hashes' that you can create template globals and other variables on the fly. Without them, you'd be stuck trying to enter/modify some table of entries in a configuration file.... or worse.
Given the relative value of servers vs programmer time, and the fact that the server
costs keep going down, whilc power goes up, it makes no sense to make code that is
hard to maintain. The use of hashes is one reason I chose GT-links over some of
the other choices.
The performance loss is negligable when compared to programmer costs. It's much
cheaper to add a new machine, a few more RAM chips, or an additional processor, than
it is to keep training, and maintaining your programmers on the code.
At one time, when a 256k upgrade was $800 on a machine that had a limit of 640k,
and a CPU clock of 4.33 on an 8-bit bus, then, code efficiency was very important.
Now, with 256 Meg chips in the $200 range or less, and CPU's running at over 800
MHz on 32 or 64 bit buses, then code efficiency in the area of an array call vs a HASH
call, becomes much, much less important.
Most programs fall apart in their basic logic, not in the use of array vs hash.
granted, driver programs, OS kernal code, and such should be highly optimized,
and array vs hash is a viable concern. Possibly even in C and C++ (which is a non-
text processing language) it would matter, but in a language like PERL, which is so
"high level" in it's abstraction levels, optimizing to this point is almost silly.
I may not be making the point properly... but in an optimized environment, such
as a search on a SPECIFIC site, using arrays or even C/C++ would be a better
choice -- but it makes the program less flexible, at only marginal improvements.
I dare say, it's almost at the point where active websites could devote a whole
processor/cpu/front-end to each connection, the way the old BBS's did with the
"pc on a card" -- one CPU for each modem connect. At that point, only the database
itself (written in an optimized language and code) and the network take the hits.
Each user has their own truely virtual machine :)
Don't think it's coming? They said that about the death of the mainframe,
and the mainframe, and shared processing is back. (ie: webserver).
I guess the bottom line point in all this is that "power" almost a relative term,
since it really depends on the hardware, and situation the software is being used in.
It's much cheaper, and more efficient to throw additional hardware at GOOD,
maintainable code, than it is to try to squeeze every drop of power from
insufficient hardware using optimized unmaintainable code.
The hardware is fleeting, the code is enduring -- :)
PUGDOG� Enterprises, Inc.
The best way to contact me is to NOT use Email.
Please leave a PM here.
You may find it helpful in many cases. 