You are right about cars, but I do not see the analogy with computers.What is the benefit of spending hours in optimizing and then shaving off 2 seconds and 100 MByte from a program that before optimization ran 5 seconds and used 250 MByte. Do you switch your computer on and off for each script you want to run? That is what I mean with "premature" optimization. My laptop is "on" the whole day I am in the office and the scripts I run really only use spare cycles and empty memory. How much power does a computer need to run an email client and an editor or a spreadsheet? If I can push CPU use above 25% with my "normal" work, I will have blisters on my fingers (and more typos than correctly typed words).
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics
| [reply] |
What is the benefit of ... <ludicrously over stated straw man>
How do you know that the OP is asking how to spend hours in order to save 2 seconds and 100 MB?
Isn't it at least vaguely possible she has an application that is currently using all of her memory and she knows that it needs to grow?
Could it be that that her application is currently taking hours or even days to run and that is simply to slow for the duty cycle she would like to be able to run?
May be her application is a web-app that is gaining currency and clients, and whilst previously the fact that it used 1 GB of memory and took 30 or 40 seconds to return the results to the users was acceptable because it was only being used by a few people and no paying clients; the numbers now using it mean that each users copy is impacting every other concurrent users copy and slowing them all down.
Maybe her choices are to spring for a substantially more expensive server/vm or to try and reduce the resources it uses so at to avoid that.
Who says that it will "take hours" to optimise her application. There are a dozen or more instances of questions on this site where OP code has been speed up by orders of magnitude and/or had its memory footprint reduced by similar factors by one or a few simple changes to the way they were coded.
The problem I have with your post is that it takes the minimal information provided -- basically the word "optimise" -- dreams up a moronic worst case scenario; applies an out-of-context, fatuous high-horse attitude and tries to score points by trotting out a party line truism of dubious benefit.
Maybe all your programs run serially in 5 seconds and never tax your laptop; but some of us run serious code that requires serious amounts of resource; and that seriously benefit from being coded in a way that makes best use of those resources available.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
Your argument goes both ways. Perhaps she has a small script that runs for 2 seconds. I don't know and you don't know, so why do you get all upset?What I said is based on solid ground: far too often I have seen that people spend too much time in optimizing things that run quite OK already. I spent lots of time optimizing programs when my computer had 16 kByte of RAM and allowed only 128 bytes of string storage and ran at a snail's pace. Yet I wrote arcadegames for it, in BASIC. But with 4GByte RAM and an 4 core i5 Intel CPU, I rarely find optimizations necessary for my purposes and it uses far less energy than my old rig. All I wanted to say is that optimization is not a goal in itself.
CountZero A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James My blog: Imperial Deltronics
| [reply] |
Obviously, both points-of-view are correct. You, BrowserUK, are constantly squeezing every ounce of capacity and performance out of a program ... because you quite legitimately need to, and you are obviously quite good at it. But the opposing point is at the same time equally valid: that Moore’s Law shows no signs of slowing down. So, it is simultaneously possible to “make poor engineering decisions” in both directions, because there are two costs here: the cost of computer hardware, and the cost of computer programmers. Both points-of-view are true and correct. It entirely depends on the context ... and the OP so-far said nada about this. So, we really don’t need to argue about that point, do we?
Addressing the OP’s original question, I would suggest these rules-of-thumb:
-
First, objectively validate that there is a valid business issue here. Beautiful cars and butt-ugly ones can be seen traveling side-by-side on the highway (and you, of course, are stuck behind the one that’s burning oil ... koff, koff), and both of them will arrive at their destination at the same time, thereby achieving the same business purpose. If one of them burned twice as much gas getting there, their owners might have no reason at all to care.
-
Second, determine if the problem should be solved with software, or hardware, or both. Of the two, software is vastly more expensive ... and vastly more vulnerable(!) to negative consequences arising from “any sort of change whatsoever, no matter how well-intentioned.” Chips are cheap, and getting cheaper all the time.
-
If you make it to point #3, it’s time to determine where it hurts the most. Which program or program(s), under what conditions (i.e. doing what?). Where is the most bang for the buck? Which change is likely to produce the most-maintainable future state?
-
Now ... measure. Profile the thing. Do not guess about anything, because you are undoubtedly wrong.
-
Next: “which one will it be ... speed? ... or space?” CPU ... or Memory? You cannot have it both ways. Ever.
-
“Don’t ‘diddle’ code to make it faster ... find a better algorithm.” That maxim from The Elements of Programming Style (Kernighan & Plauger) is still true. To make your program run significantly faster, or to use significantly less memory (pick one), you will have to devise (or find) a better algorithm. There is, I aver, no other way to do it.
-
Now ... prototype. Put your pinkie-toe into the water and keep your fourth toe dry. Set up an expendable test-case to demonstrate that your idea is both correct and useful under real conditions.
-
Now implement your change ... but you’re not done yet! You have just made major changes to the program. Now, you must construct test cases to prove that the old and the new versions produce identical results in all cases, and that your expected improvements were in fact realized.
| |
