|
Code simplicity and correctness gives better readability and maintainability.
If you think some other optimizations are needed, measure first to be certain of what, if anything, really needs to be optimized. Only then spend your time optimizing.
|
|
|
|
|
I call that Refactoring. Optimization ~= speed & efficiency; Refactoring ~= simplicity, understandability, maintainability. 
In my experience, the two are kind of counter-intuitive. Optimization of code for performance or efficiency usually results in something that is LESS understandable than code that is refactored for simplicity and maintainability. Its a continuous balancing act between acceptable speed and efficiency vs. acceptable code simplicity, understandability, and maintainability.
|
|
|
|
|
Jon Rista wrote: Refactoring ~= simplicity, understandability, maintainability.
True, if done correctly! 
I usually write simple code from the start and don't do much refactoring.
My optimization steps usually revolve around implementing and profiling different algorithms. Some times a O(log n) algorithm is worse than a O(n) and it is not always obvious why. The best performing algorithms are not always the ones with the most complex, least maintainable code. That said, in general, I also tend to see a trade off between simplicity and performance.
|
|
|
|
|
PedroMC wrote: I usually write simple code from the start and don't do much refactoring.
I generally try to take the same approach (I'm probably the most fastidious programmer on earth...a stickler for proper structure, naming, ordering of code, commenting, etc.) However, when you work in a development shop where there are over a dozen dev teams of 5 or so people each, the volume of code that does not need regular refactoring is pretty small (sometimes the same subsystem needs to be refactord many times).
In my experience, most programmers are generally not concerned with code cleanlieness, clarity, simplicity, maintainability or performance...they just write code to meet needs of a specification and move on to the next task. In such a real-world environment, code reviews and refactoring are essential processes that help ensure that appropriate level of optimization vs. maintainability.
|
|
|
|
|
PedroMC wrote: If you think some other optimizations are needed, measure first to be certain of what, if anything, really needs to be optimized.
And when you do that, be sure to use the minimum supported hardware, not your dev machine
|
|
|
|
|
Nemanja Trifunovic wrote: And when you do that, be sure to use the minimum supported hardware, not your dev machine
Yes, that is always a good advice, and not just for performance testing.
|
|
|
|
|
I always optimize for maintenance first. If that means it runs more slowly, so be it.
For other kinds of optimizations, I live by the rule: Optimize written code.
It might mean rewriting completely, but that turns out to be rare. Whatever I need to optimize in a particular project, I want to measure a maintainable implementation before I make any changes that might be harder for programmers to pick up in a year.
Of course, optimized code is not *necessarily* harder to maintain (although we usually think of it that way), but I definitely want to start with a baseline. It's amazing how often the most maintainable implementation is fast/small/high throughput/etc. enough.
|
|
|
|
|
Dang, beat me by 5 minutes.
Like Roger's Rangers said, you got there the firstest with the mostest.
The only difference I have with what you said is"
Seth Morris wrote: I live by the rule: Optimize written code.
I work with "it's easier to optimize working code than to make optimized code work"
Silver member by constant and unflinching longevity.
|
|
|
|
|
|
It said 5 minutes when I started typing. 
I guess that puts me at about 3 words per minute, typing 
Silver member by constant and unflinching longevity.
|
|
|
|
|
Which makes you a good coder
|
|
|
|
|
So far no one have selected this option. Where are all the Green Developers 
Yusuf
Oh didn't you notice, analogous to square roots, they recently introduced rectangular, circular, and diamond roots to determine the size of the corresponding shapes when given the area. Luc Pattyn[^]
|
|
|
|
|
It's not really clear how to do this except avoid wasting cycles. To me this means you have to write everything in assembly language because C++ definitely wastes cycles and don't get me started on .NET...
John
|
|
|
|
|
John M. Drescher wrote: It's not really clear how to do this except avoid wasting cycles
Minimize hard disk IO?
|
|
|
|
|
That's surely another. Probably more difficult depending on the problem and probably less fruitful in most applications being that most CPUs use 2 times the power what a hard drive uses at idle. and 5 to 15 times what a hard drive does when both are under full load.
John
|
|
|
|
|
John M. Drescher wrote: It's not really clear how to do this
Easy: Don't use the processor and don't use the disk or anything else (or the program should immediately shut down the machine...) 
Regards
Thomas
www.thomas-weller.de
Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.
Programmer - an organism that turns coffee into software.
|
|
|
|
|
I think this is an issue mainly on mobile devices, where battery power is at a premium.
|
|
|
|
|
I don't do treehugging
|
|
|
|
|
The trees around here don't encourage hugging.
|
|
|
|
|
If it's easy to maintain I don't have to run my development system as much.
|
|
|
|
|
Yusuf.A wrote: Where are all the Green Developers
They have all moved back to Bob's home planet.
|
|
|
|
|
For almost everything I developed in the last ten years it was either memory or IO that was the bottleneck.
|
|
|
|
|
Then you're just not trying hard enough!
cheers,
Chris Maunder
The Code Project Co-founder
Microsoft C++ MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
