Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am only developer working on a project. The functionality that I have coded works to expectations(desired result) but since I am the only one I don't know if I can do anything better to it. How do I determine if my code is optimized (I want to increase the performance of some features)?

One thing that comes into mind is Code Review but there is no one free over here to review my code. I just keep on trying with alternate logic but at times things get stagnant and really dirty. Is there any other possible way?

share|improve this question
4  
Free Code Review - codereview.stackexchange.com –  zafarkhaja May 18 '12 at 11:39
7  
Have you profiled your code? If not, this is the first thing to do to identify hot spots and eventual candidates for algorithm changes/low-level optimizations. –  K.Steff May 18 '12 at 11:41
    
Github.......... –  RSM May 18 '12 at 12:55
1  
If your application meets then you should not think about optimization. A good developer develops what is required, not less, not more. –  Mert May 18 '12 at 13:17
    
If this is code for a company, public review is probably not an option. –  JeffO May 18 '12 at 13:37

6 Answers 6

up vote 12 down vote accepted

Ask youself:

  1. What do you want to optimize for?
  2. Do I really need to optimize for this particular thing, or is it actually good enough?

As far as "what for" goes, a few possible answers and what you should do:

  • maintainability - the best test here is real-world production usage, but using that alone yields some kind of a vicious circle. However, you can have someone else review your code; you can check if others can work with it well; you can run over a checklist of what you consider code smells, or, more positively, a checklist of what you consider must-haves for well-written code. Document everything, and have someone else read the documentation and tell you which parts are unclear.
  • correctness and reliability - write automated tests that cover everything that can be meaningfully tested, and design your code to be as testable as possible. Put on your destruction monkey hat and see if you can use your own code in a way that breaks it; then go fix it. Write a detailed test plan that covers all the functional and technical requirements, including 'negative' cases (i.e., describe what you expect the code to do when you use it in unintended ways); let someone else execute the test plan and consider all negative responses bugs in either the design, the code, or the test plan.
  • run-time performance - there is no replacement for profiling here. Before attempting to optimize anything for performance, first make sure it is correct; then make sure the part you are going to optimize is indeed a problem area. Then change one thing, and measure the performance before and after. Don't forget to test against realistic data, including huge datasets - many algorithms work fine (even faster) for small datasets, but come to a grinding halt when the dataset exceeds a certain size. Optimize algorithms before code - algorithms can make an exponential difference, while optimizing code practically never wins you any gain beyond linear. Also, go for the easy fixes first: compiler optimization settings (these are basically free), simple refactorings (pass-by-const-reference instead of pass-by-value and such), caching (can be done at several levels, you'll have to judge where it makes the most sense), and whatever can be implemented easily in the code you already have. Note that there are several orthogonal measurement for "performance", such as CPU load, latency, memory footprint, etc.; quite often, you have to balance one of those against another, e.g. reducing CPU usage at the cost of an increased memory footprint. See Mark Booth's comment for more details. And don't forget, sometimes (though not often) "throw more hardware at it" is the correct answer.
  • profitability - analyze which features make you the most money, and what parts of the application are possible stumbling blocks for generating more revenue. For web applications, tracking usage patterns is probably the most promising way to do this. Then estimate how much you would have to spend on each part to fix it, and by how much it would increase your revenue. From there, it should be clear which issues you should take up first.
share|improve this answer
1  
Great answer, it might be worth mentioning that even run-time performance can be split into several separate performance metrics such as memory, latency and throughput. Optimising for a small memory footprint could be a requirement for scalability, while optimising for throughput could affect latency and vice versa. If writing a enterprise app, being able to handle 1000 transactions a second with a one second response time might be best, whereas a heart monitor might need to handle only 100 events per second, but need to respond within a tenth of a second - a 1 second response could be fatal. –  Mark Booth May 18 '12 at 13:01
    
@MarkBooth: Excellent point. I tried to keep the answer concise, which is why I didn't go into more detail. I added a bit referring to your comment though. –  tdammers May 18 '12 at 14:51
1  
Thanks, and if I could I'd +1 again for sometimes... "throw more hardware at it" is the correct answer. *8') –  Mark Booth May 18 '12 at 15:07

There hardly exists any code that can't be made faster. As this post shows, no matter what you do to speed up the code, there is almost always something more you could do. That's because changes that initially would not have been much help become a lot more significant after other sources of slowness have been removed.

Where did you get the idea that code reviewers could tell you how to make code faster? I often get asked how to make code fast, but that's like asking a doctor to diagnose without examining the patient. Even eyeballing the code is of little use.

The fundamental skill of performance tuning is diagnosis. Anybody who suggests otherwise is giving you a WAG. Here's how I do it.

share|improve this answer

I'd say you need to look for

  1. Is it fast enough? I wouldn't spend too much time bringing page load time from 1 second down to 0.1sec for a site that will see 50 visitors a day.

  2. Open your solution, and try to look at your code like if you've never seen it before. Does it make sense ? Can you read it, and understand what it does and why it does it like that ? Maintainability is the key (unless it's one-off piece that you will never run again).

  3. If you want a somewhat a better quantified measure, VS (if you're using .NET) has a code analysis tool, which will give you a rough idea of your code maintainability/complexity.

share|improve this answer

If the code actually conforms to the implicit and explicit expectations then you might not need to optimize it at all. Your time might be better spent elsewhere adding more functionality.

The way you phrase your question makes me think that you feel there are some implicit expectations that you have not fully achieved with your code though. Maybe you should check with your client first to see what they actually expect.

Be careful that you are not stepping into the trap of gold-plating.

If you are still confident of wanting to optimize after the above, then follow tdammer's advice.

share|improve this answer
    
+1 for gold-plating reference! –  Jarrod Roberson May 19 '12 at 4:16
code.optimized = users.happyWithPerformance ? true : false;
share|improve this answer
    
+1 for the idea expressed, -1 for the ugly ternary operator. –  Mason Wheeler May 18 '12 at 14:28
1  
@MasonWheeler the ternary operator is not ugly. though it is often abused. –  Ryathal May 18 '12 at 14:30
3  
I like the ternary operator, but you're right that it gets abused. Since happyWithPerformance must be boolean, it's being abused right now! :P –  GenericJon May 18 '12 at 15:09
    
Surely no code can be said to be truly "optimized" by this metric unless the users are as happy with it as they can possibly be? –  thesunneversets May 18 '12 at 17:14

Profile your app and look in which functions your code spends the most time, then go about optimising those specific functions. You could spend days optimising one function only to discover that it's only called a couple of times, whereas there are little functions that get called hundreds of times, these are the ones to look at.

Replacing objects with low-level data types sometimes helps, also make sure that in conditionals the most likely conditions are evaluated first.

Also try playing with build settings, like compiler optimisation levels, stripping debug symbols and so on.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.