Reply to thread

Message

I'm an experienced C# Software Developer (read not engineer) and I have another view of "performance tuning" I'd like to share.

DO NOT OPTIMIZE CODE UNLESS IT’S REQUIRED!!!

I've see way too much code that’s been "optimized" for maximum performance that’s become so unreadable and maintainable its nearly impossible to fix minor bug never mind add new features! Developers can spend countless hours coding "better for loops" and learn the details of C# garbage collection and still write horribly bad performing code. Your tips, although very useful in specific situations, if applied to every line of code in MP or any other application will lead to increased dev times and even project failure. Think about your point 2 (treat new classes like C++), If I had to dispose every object I created why the HELL would I use C#!?!?! I might as well use C++.

Now back to my main point. The best way to increase performance is to target problem areas and try to find better ways of implementing specific problem functions/algorithms. The hard part is finding these problem areas. Code reviews by more experienced developers are a good way to do this, but sometimes that’s not even enough. Luckily there are a whole group of tools dedicated to helping you do this. They are called Code and Memory Profilers... learn them and love them. I've personally used DevPartner with great success. (they have a free version here)
http://tinyurl.com/2oct4
They help you find places where you are using the most clock cycles and memory. In most cases the profiler can point you directly at specific lines of code in your algorithms and framework calls. A few examples I've run into are:
1) Expensive searches (ie a simple linear search instead of a binary search)
2) Unnecessary memory allocation (ie creating new object in for loops)
3) Using .NET Framework reflection (ie using object.GetType() everywhere)
4) Framework bugs (I found a memory leak in the .NET XML module to do with a specific version of an overloaded method! Which M$ fixed in a new release of the Framework  )
These are more subtle problems that can creep up in even the most “optimized” code base. In my opinion its better to make your code readable and maintainable so that when these issues come up you are able to find the problem areas and take care of them.

Sorry if I came off a little harsh, but I’m sick and tired of junior devs (and some “sr” ones too !) running around “optimizing” their code for no reason at all and then me having to jump in and fix a major issue because they screwed it up so bad that they can’t even read their own code! </rant>

<blockquote data-quote="Anonymous" data-source="post: 6741">I'm an experienced C# Software Developer (read not engineer) and I have another view of &quot;performance tuning&quot; I'd like to share. DO NOT OPTIMIZE CODE UNLESS IT’S REQUIRED!!!I've see way too much code that’s been &quot;optimized&quot; for maximum performance that’s become so unreadable and maintainable its nearly impossible to fix minor bug never mind add new features! Developers can spend countless hours coding &quot;better for loops&quot; and learn the details of C# garbage collection and still write horribly bad performing code. Your tips, although very useful in specific situations, if applied to every line of code in MP or any other application will lead to increased dev times and even project failure. Think about your point 2 (treat new classes like C++), If I had to dispose every object I created why the HELL would I use C#!?!?! I might as well use C++.&nbsp; Now back to my main point. The best way to increase performance is to target problem areas and try to find better ways of implementing specific problem functions/algorithms. The hard part is finding these problem areas. Code reviews by more experienced developers are a good way to do this, but sometimes that’s not even enough. Luckily there are a whole group of tools dedicated to helping you do this. They are called Code and Memory Profilers... learn them and love them. I've personally used DevPartner with great success. (they have a free version here) <a href="http://tinyurl.com/2oct4" target="_blank">http://tinyurl.com/2oct4</a> They help you find places where you are using the most clock cycles and memory. In most cases the profiler can point you directly at specific lines of code in your algorithms and framework calls. A few examples I've run into are:1) Expensive searches (ie a simple linear search instead of a binary search)2) Unnecessary memory allocation (ie creating new object in for loops)3) Using .NET Framework reflection (ie using object.GetType() everywhere)4) Framework bugs (I found a memory leak in the .NET XML module to do with a specific version of an overloaded method! Which M$ fixed in a new release of the Framework  )These are more subtle problems that can creep up in even the most “optimized” code base. In my opinion its better to make your code readable and maintainable so that when these issues come up you are able to find the problem areas and take care of them.Sorry if I came off a little harsh, but I’m sick and tired of junior devs (and some “sr” ones too !) running around “optimizing” their code for no reason at all and then me having to jump in and fix a major issue because they screwed it up so bad that they can’t even read their own code! &lt;/rant&gt;</blockquote>

[QUOTE="Anonymous, post: 6741"] I'm an experienced C# Software Developer (read not engineer) and I have another view of "performance tuning" I'd like to share. DO NOT OPTIMIZE CODE UNLESS IT’S REQUIRED!!! I've see way too much code that’s been "optimized" for maximum performance that’s become so unreadable and maintainable its nearly impossible to fix minor bug never mind add new features! Developers can spend countless hours coding "better for loops" and learn the details of C# garbage collection and still write horribly bad performing code. Your tips, although very useful in specific situations, if applied to every line of code in MP or any other application will lead to increased dev times and even project failure. Think about your point 2 (treat new classes like C++), If I had to dispose every object I created why the HELL would I use C#!?!?! I might as well use C++. Now back to my main point. The best way to increase performance is to target problem areas and try to find better ways of implementing specific problem functions/algorithms. The hard part is finding these problem areas. Code reviews by more experienced developers are a good way to do this, but sometimes that’s not even enough. Luckily there are a whole group of tools dedicated to helping you do this. They are called Code and Memory Profilers... learn them and love them. I've personally used DevPartner with great success. (they have a free version here) [url]http://tinyurl.com/2oct4[/url] They help you find places where you are using the most clock cycles and memory. In most cases the profiler can point you directly at specific lines of code in your algorithms and framework calls. A few examples I've run into are: 1) Expensive searches (ie a simple linear search instead of a binary search) 2) Unnecessary memory allocation (ie creating new object in for loops) 3) Using .NET Framework reflection (ie using object.GetType() everywhere) 4) Framework bugs (I found a memory leak in the .NET XML module to do with a specific version of an overloaded method! Which M$ fixed in a new release of the Framework  ) These are more subtle problems that can creep up in even the most “optimized” code base. In my opinion its better to make your code readable and maintainable so that when these issues come up you are able to find the problem areas and take care of them. Sorry if I came off a little harsh, but I’m sick and tired of junior devs (and some “sr” ones too !) running around “optimizing” their code for no reason at all and then me having to jump in and fix a major issue because they screwed it up so bad that they can’t even read their own code! </rant> [/QUOTE]