|
 The "optimal" goal is no end-user complaints!
|
|
|
|
|
Nowadays, I'm mostly working with having our website fetch and present data to our field staff. Bandwidth is a frequent gripe -- anyone who has had to use a hotel Wi-Fi knows what I mean -- so balancing page bloat with how often a user has to ask for more data is an ongoing concern.
|
|
|
|
|
Generally, this translates into faster execution, but I try to reduce the source size.
This can be interpreted as maintainability or readability as well. Like somebody else said below, customers are only good for testing - and they're not particularly good at it either 
I love go-o-o-o-ld!
|
|
|
|
|
|
What's
a
line
of
code?
Provided you use a decent language and avoid compiler directives and such you only need one line anyway:
int main ( int argc , char* argv[] ) { int result = 0 ; printf ( "%d\n" , argc ) ; if ( argc > 1 ) { printf ( "Hello, %s\n" , argv [ 1 ] ) ; } return ( result ) ; }
|
|
|
|
|
|
Counting lines already did not work so well with macro assemblers, much less with a modern language. A thousand lines with simple instructions may execute faster than a single line that calls the function KillAllPerformance().
It's like determining the speed of a car by measuring its height and multiplying it by the circumference of its wheels. 
Sent from my BatComputer via HAL 9000 and M5
|
|
|
|
|
I have seen cases where there was a single function call in the framework to read a csv file into a table but the developer read the file line by line, split the line on the comma character and then created individual rows and then added them to a table 
I love go-o-o-o-ld!
|
|
|
|
|
Fewer lines of code are only a good metric for performance in scripting languages where you say "1 line of code = 1 statement". Here the reason is that most scripting languages scale with the number of statements, since the interpreter takes the most time (much more than the individual statements).
Otherwise your argument is no true in a lot of occasions for compiled languages either. Examples of performance optimizations that always result in more lines of code are loop unrolling, using special vector instructions, manual synchronization, ...
|
|
|
|
|
What are some good power optimization resources so I can learn more about it..????
--Recently heard @build someone comment that there isn't yet a good way to test this ... were they right?
"The conversations he was having with himself were becoming ominous."-.. On the radio...
If you want answers: provide lots of information, including tiny details!
|
|
|
|
|
I am mainly PLC-Programmer so I have to be very carefull with the amount of memory that I use and the speed of the process since both are limited for me in most of the projects.
My actual main project is something I have been from the very beginning. We are handling 35% to 40% more data than another line programed 2 years ago by other guy. With exactly the same hardware my project is consuming 20% less memory and executing around 400% faster than the other line. Main difference between styles is: Object-Intances versus Reference & Pointers.
New generation of PLCs is seeing seing the light since some time ago, they are supposed to be the panacea of place and speed, but since I have any of them in my hands yet...
I try to do my code paying attention to flexibility and reusability as well. And at least but not last, maintenance: clean and easy sources are very important for me as well (see poll of the last week) and not only thinking on other programmers. If I have to modify something of my own code in a year or two I want to be able to understand my current way of thinking and not to stare at my own function as... what the hell was I thinking when I did that?
But the first and more important thing in business is:
It has to work good and be ready as fast as possible. Closed-Price projects are usually not so generously calculated and... Time is money (even the spare time).
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
Most of the applications I deal with are heavily related to data handling, so disk I/O is one of the things to keep an eye on.
|
|
|
|
|
My project depends heavily on ipc, cutting down on sending huge amounts of data on dbus has had an amazing impact on performance.
|
|
|
|
|
|
That's what I focus on for everything I write. Occasionally I need to deal with memory and speed, and those usually involve multithreading as well.
Marc
|
|
|
|
|
When I was developing client-side desktop software, I was concerned about things like laptop battery life and binary size. Now that I am developing for servers, CPU matters most, especially CPU cache friendliness.
|
|
|
|
|
Of late, it has been necessary that I create generic interface so that other developer with no familiarity with the language(s) can plug-and-play.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
... is usually much more important to optimise than execution speed, memory use, or any of the other techie options.
|
|
|
|
|
In other words - who cares for the customers? The important thing is that developers are happy
|
|
|
|
|
Exactly! Customers are only useful for testing.
|
|
|
|
|
chris5gd wrote: Customers are only useful for testing
+1. I'll just add they are bad at testing too. Sure, they'll find a bug, but very few of them are able to write a useful bug report.
|
|
|
|
|
Hard luck. Not enough detail to reproduce, no fix.
|
|
|
|
|
Given that probably over 95% of all code has practically zero impact on ultimate code performance, I find it better to write all code with the emphasis on readability, maintainability etc, and only performance tune the stuff that really is on a critical path.
Cheers, Des
P.S. All your pie are belong to us
|
|
|
|
|
Des Ward wrote: 95% of all code has practically zero impact on ultimate code performance
Source?
|
|
|
|
|
30+ years of experience
Cheers, Des
P.S. All your pie are belong to us
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
