posted 6 years ago
-
1
-
-
-
-
Yes, deleting them (or any log calls) will improve performance.
The rules for increasing performance are simple and immutable:
1) instrument code
2) find where it is actually spending time when you execute the code
3) remove the biggest bottle neck
4) if you have improved it enough, go out for dinner and beer.
5) if not, go to step 2.
The rules for increasing performance are simple and immutable:
1) instrument code
2) find where it is actually spending time when you execute the code
3) remove the biggest bottle neck
4) if you have improved it enough, go out for dinner and beer.
5) if not, go to step 2.
posted 6 years ago
fixed that for ya...
Pat and i are basically saying:
1) Don't worry about performance unless you have a DOCUMENTED NEED.
2) use some tool to determine where things REALLY slow down, since if you guess, you will be wrong.
3) Trying to write code that is 'fast', at the expense of 'readable' or 'understandable' is a loosing battle. You will inevitably spend more time fixing/debugging poorly written code than users will ever save by writing it that way.
Pat Farrell wrote:
The rules for increasing performance are simple and immutable:
0) determine actual metrics on what performance needs to be
1) instrument code in clear, readable, easy to follow manner
1a) if code meets documented performance metrics, go to step 5...
2) find where it is actually spending time when you execute the code
3) remove the biggest bottle neck
4) if you have not improved it enough, go to step 2
5) go out for a beer
fixed that for ya...
Pat and i are basically saying:
1) Don't worry about performance unless you have a DOCUMENTED NEED.
2) use some tool to determine where things REALLY slow down, since if you guess, you will be wrong.
3) Trying to write code that is 'fast', at the expense of 'readable' or 'understandable' is a loosing battle. You will inevitably spend more time fixing/debugging poorly written code than users will ever save by writing it that way.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
posted 6 years ago
I like this site and newsletter by a well known java programmer.
For a fun time do a google search for "premature optimization is the root of all evil" - or look at this wikipedia page.
Bill
For a fun time do a google search for "premature optimization is the root of all evil" - or look at this wikipedia page.
Bill
Kaushik Baral
Ranch Hand
Posts: 32
posted 6 years ago
You first need to explicitly define what "performance" means to your application. Speed of transactions, number of concurrent users, speed of web page generation, speed of database queries, etc.
Once you have defined what exactly needs possible performance improvements, then you need to measure what you currently have.
With your documented Performance requirements and your documented baseline measurements, you will be ready to start to think about how you can improve performance.
Keep in mind that many micro-level mille-second speed improvements are typically not worth the trouble or hassle. And in many cases, make code more confusing. It is usually better to
strive for a greater level of understandability than shaving a couple of seconds off of a process.
Once you have defined what exactly needs possible performance improvements, then you need to measure what you currently have.
With your documented Performance requirements and your documented baseline measurements, you will be ready to start to think about how you can improve performance.
Keep in mind that many micro-level mille-second speed improvements are typically not worth the trouble or hassle. And in many cases, make code more confusing. It is usually better to
strive for a greater level of understandability than shaving a couple of seconds off of a process.
