I really don't think that is 'nuff said. In fact
I said quite a bit more about the topic at Re (tilly) 1: What does "efficient" mean?!?,
as well as in other nodes.
As obvious as it may be to you that you should never be
knowingly inefficient, optimizing for the wrong problem
is a waste of overall resources.
If you disagree, then I invite you to look at the memory
use of Perl and decide to work in C and assembler until
you see the light. | [reply] |
Well at least you have a more mature response than others. This is off topic from the orig thread, but...
Tradez makes my same point a post or two below mine.
My issue is that in my job I see applications developed that require multiple servers with gigabytes of ram to run when they could run off of one server. The only reason this happens is because the application developers were sloppy. The "Ram is cheap and it's not my dime anyway!" attitude caused this. We brought in another group to do code review, optimized their code, and now the same app runs even faster on a single machine. The other two machines have been allocated for growth as opposed to a requirement to run.
There's something to be said about taking pride in your work. The "ram is cheap" attitude seems to me to go against the general attitude of the Perl monks, "how can I do this, or how can I do it better?"
While this coderef question may not be a good example, it should still not be easily dismissed without a real answer in a place where questions are welcomed.
| [reply] |
One general attitude here is that it is important to learn what attitudes are important.
Take your example. Round figures let us say that a server costs $5,000 and a developer costs $60,000. (Actually both cost far more, supporting a developer includes office space, insurance, etc. Supporting a server takes up front money, installation, configuration, and ongoing administration. But the basic point remains the same.) Then a brand new machine is worth one month of one developer's time.
If you have 4-5 developers, that means that one week of wasted time is worth a brand new server. If your code review took one month, you lost money doing it. If you have an application that needs to scale, then you might find it well worth while. If there are complications with having multiple servers in your application, then keeping to a single server may be worth quite a bit of bother. If you are shipping to customers, then keeping within typical resources matters a lot. Rules of thumb tend to have lots of exceptions.
But still this is the economics of, "RAM is cheap." Developers shouldn't be stupid about it. But being only slightly concerned about memory usage while paying attention to maintainability etc is not being lazy. It is an appropriate allocation of resources for the typical situation. (If your situation varies, then optimize appropriately.)
| [reply] |