Does anybody really use a Profiler?
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
You don't need a profiler to find a problem with this code snippet. :)
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;But a profiler can come in mighty handy when trying to identify the bottleneck in complex, old code that no longer seems to scale well. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
When people say "use a profiler" they mostly say "use whatever method you have on hand to measure up your code and gather data about the performance of your code" A profiler is one tool to do it; using a stopwatch is another tool;
I'd rather be phishing!
-
You don't need a profiler to find a problem with this code snippet. :)
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;But a profiler can come in mighty handy when trying to identify the bottleneck in complex, old code that no longer seems to scale well. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Well, you rarely inherit an old application and get told "everything in it is slow"... you get told "functionality 1 through x is slow. So you really only identity bottlenecks in specific pieces of code.
-
When people say "use a profiler" they mostly say "use whatever method you have on hand to measure up your code and gather data about the performance of your code" A profiler is one tool to do it; using a stopwatch is another tool;
I'd rather be phishing!
Maximilien wrote:
When people say "use a profiler" they mostly say "use whatever method you have on hand to measure up your code and gather data about the performance of your code"
A profiler is one tool to do it; using a stopwatch is another tool;LOL... I also like when people misuse the term "refactor". My ex-boss would ALWAYS say he was "refactoring" code on every change he would make when that's not at all what the term means.
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
SledgeHammer01 wrote:
Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow.
Especially if this 'blöck' of code is made up of several class hierarchies and runs in multiple threads. If somebody does not instantly identify the bottlenecks and sections in need of some optimization, then he should start flipping burgers instead of stealing our time. :-) Seriously, a profiler is intended for bigger jobs than finding out wether or not a single method is doing its job. I have been playing with graphics ever since my first computer and in that area even the best code is not fast enough. Profilers have been among my favorite tools ever since I got my fingers on one.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript. -
Well, you rarely inherit an old application and get told "everything in it is slow"... you get told "functionality 1 through x is slow. So you really only identity bottlenecks in specific pieces of code.
SledgeHammer01 wrote:
functionality 1 through x is slow
If only it were as simple as that in reality. :-D The enterprise app I work on has several moving parts and is continuously growing. For the most part, it works fine. But once in while we encounter a dataset that causes an unexpected performance problem. A profiler has helped address problems such as these, where the solution isn't immediately obvious. In many cases it's not simply "crappy code" that's to blame, but a lack of understanding of all possible input conditions. Often, this leads to re-engineering parts of the app or modifying workflow rules in order to better handle the load. BTW, performance analysis is an area in which I don't pretend to have any expertise. At work we have performance engineers who eat, drink and breathe scalability. I take my hat off to them. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
SledgeHammer01 wrote:
Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow.
Especially if this 'blöck' of code is made up of several class hierarchies and runs in multiple threads. If somebody does not instantly identify the bottlenecks and sections in need of some optimization, then he should start flipping burgers instead of stealing our time. :-) Seriously, a profiler is intended for bigger jobs than finding out wether or not a single method is doing its job. I have been playing with graphics ever since my first computer and in that area even the best code is not fast enough. Profilers have been among my favorite tools ever since I got my fingers on one.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.CDP1802 wrote:
a profiler is intended for bigger jobs than finding out wether or not a single method is doing its job
:thumbsup: /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
Profiler's are a good tool, for the correct situation. If you don't know how to use them, then it really doesn't do you any good. Our team uses them in special situations, and they have really helped us out with isolating some tricky performance issues.
-
SledgeHammer01 wrote:
Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow.
Especially if this 'blöck' of code is made up of several class hierarchies and runs in multiple threads. If somebody does not instantly identify the bottlenecks and sections in need of some optimization, then he should start flipping burgers instead of stealing our time. :-) Seriously, a profiler is intended for bigger jobs than finding out wether or not a single method is doing its job. I have been playing with graphics ever since my first computer and in that area even the best code is not fast enough. Profilers have been among my favorite tools ever since I got my fingers on one.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript. -
+1 for your signature, "The language is JavaScript. that of Mordor, which I will not utter here" :)
Only Orcs use something that is not typesafe, not object oriented, interpreted and actualy is something like Lisp hiding behind a C-like syntax. I thought that such things (except for my personal dislike of functional languages) had been left to amateurs 30 years ago.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript. -
I recently posted a question: "I am trying to solve this problem. I solved it by using Solution1. I'm not happy with Solution1 because it is going to be a performance issue and I want to use Solution2 which I think will be a lot better. How do people typically implement Solution2?" So, of course, somebody chimes in and responds: "What makes you think Solution1 is a performance issue? Don't guess. Use a profiler!" Are you serious? LOL... Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow. If you rely on a profiler as a crutch, you should really work on your analytical skills as I think that's a requirement to be a good software ENGINEER and not just a coder. I dunno, maybe it's just a talent I have, but I've never used a profiler more then maybe once or twice and I've never had an issue QUICKLY optimizing the hell out of code. For example, just the other day, a junior co-worker complained to me that he was given a simple task and he has it working, but it's taking 2.5 minutes to run. I agreed that was waaay to slow and asked him how he did it. He said it was very basic, he just did this 1 simple step. So I said, it would be a lot faster if you used this 2 step solution instead. At first, he argued with me (cuz he's really cocky) that my 2 step solution couldn't possibly be faster then his 1 step solution. I told him that my 2 step solution would blow his 1 step solution out of the water guaranteed and that it would finish "instantly". He still didn't believe me (cuz he's really, REALLY cocky). Finally, after trying more stuff that didn't work, he implemented my 2 step solution and what do you know... it came back in "0ms" vs his 1 step solution that took 2.5 minutes. To me, optimizing code & identifying bottlenecks isn't rocket science. It's always the same: 1) move any repetitive work that's static outside the loop 2) cache objects that are expensive to create and setup 3) cache results that are expensive to calculate 4) don't use reflection in highly trafficked code 5) don't use linq in highly trafficked code 6) don't inline SQL code, use stored procs 7) don't suck down an entire database, only grab the data as you need it Those 7 basics will generally get you at least 50% of the way towards optimized code. There are some more "advanced" concepts that'll get you the rest of the way (and there are of course some other basic things I didn't list). I think if you use C# every day
However, no one has mentioned the the core reason that profilers exist: We write code in high-level languages which get converted to machine language (CPU Operation Codes). A profiler can tell you that your code which is only 1 line (of high-level language) actually takes 5 CPU operations to complete. That part isn't actually obvious, because we write code at one layer and most people who haven't written assembly don't really understand this. Mostly you get lucky that the high-level languages and built in compilers optimize even very badly written high-level language into a smaller number of CPU operations. They do so much work these days, your code may not even be represented the way you think it is by the time it gets to the CPU. So, unless you are saying you can turn your high-level language into CPU operations in your head, you can still write code you think will perform well which actually somewhat inefficient when turned into OP Codes tha the CPU actually runs. That's where a profiler can come in handy. You can see what your code really does to the poor little processor. One of the best and easiest to use profilers is in ICSHarpCode's SharpDev Studio. Try out the IDE (Integrated Dev Environment) and I think you'll be amazed.SharpDev Studio - Open Source & Free [^] Hopefully I've provided some food for thought.
-
SledgeHammer01 wrote:
functionality 1 through x is slow
If only it were as simple as that in reality. :-D The enterprise app I work on has several moving parts and is continuously growing. For the most part, it works fine. But once in while we encounter a dataset that causes an unexpected performance problem. A profiler has helped address problems such as these, where the solution isn't immediately obvious. In many cases it's not simply "crappy code" that's to blame, but a lack of understanding of all possible input conditions. Often, this leads to re-engineering parts of the app or modifying workflow rules in order to better handle the load. BTW, performance analysis is an area in which I don't pretend to have any expertise. At work we have performance engineers who eat, drink and breathe scalability. I take my hat off to them. /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
OIC... I guess that's why I was wondering if it's "just me" :). If I encountered a problem with a specific dataset that was causing a performance issue, I guess I'd do my usual thing with that dataset as the input. The biggest issue I have seen with my limited experience with profilers as I said in my original post is that they generate way too much noise to be useful. By the time you dial it in and filter out all the noise, you could have just as easily done it manually. Then there is the profiler misleading you as well as in my dictionary example. I guess once you do a few a optimization jobs manually, you start to learn where the performance issues are. I was recently surprised to learn that Enum.HasFlags() is a performance killer (such a simple method, you'd think). I found that out during my normal process, but now going forward, I'd know that's one of the items I need to look out for on an optimization job.
-
Only Orcs use something that is not typesafe, not object oriented, interpreted and actualy is something like Lisp hiding behind a C-like syntax. I thought that such things (except for my personal dislike of functional languages) had been left to amateurs 30 years ago.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript. -
SledgeHammer01 wrote:
Personally, I think anybody who has been programming a while should be able to look at a block of code for a few minutes and instantly identify why it's slow.
Especially if this 'blöck' of code is made up of several class hierarchies and runs in multiple threads. If somebody does not instantly identify the bottlenecks and sections in need of some optimization, then he should start flipping burgers instead of stealing our time. :-) Seriously, a profiler is intended for bigger jobs than finding out wether or not a single method is doing its job. I have been playing with graphics ever since my first computer and in that area even the best code is not fast enough. Profilers have been among my favorite tools ever since I got my fingers on one.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.Are you talking about thread deadlocking and/or resource contention? I wouldn't consider deadlocking a performance issue, but I guess you could take it as one. I'd consider it more a threading issue. Big performance killer in multi-threading is if you use a lot of thread synchronization when you don't absolutely have to. Microsoft has a nice solution for that with the TPL library. I've not done games or graphics programming, so I couldn't comment on that portion.
-
Profiler's are a good tool, for the correct situation. If you don't know how to use them, then it really doesn't do you any good. Our team uses them in special situations, and they have really helped us out with isolating some tricky performance issues.
Can you share a specific issue that you consider a tricky performance issue? Just curious... ;).
-
Can you share a specific issue that you consider a tricky performance issue? Just curious... ;).
Is the issue in the WPF app or in the WCF service? So, you have a WPF app for instance, that has a lot of code in its own right, and it gets its data via WCF service. Is the performance degradation in the WPF app or in the WCF service? Well, you can tell if it is the WCF service if the getter methods are showing longer than usual turn a rounds. It can point you in the right direction, and sometimes at the actual method. You usually use a profiler in big to enterprise level solutions. Using them on one method is a little lame, IMHO.
-
Only Orcs use something that is not typesafe, not object oriented, interpreted and actualy is something like Lisp hiding behind a C-like syntax. I thought that such things (except for my personal dislike of functional languages) had been left to amateurs 30 years ago.
The language is JavaScript. that of Mordor, which I will not utter here
I hold an A-7 computer expert classification, Commodore. I'm well acquainted with Dr. Daystrom's theories and discoveries. The basic design of all our ship's computers are JavaScript.CDP1802 wrote:
Only Orcs use something that is not typesafe, not object oriented, interpreted and actualy is something like Lisp hiding behind a C-like syntax.
I thought that were klingongs ;P
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.
-
However, no one has mentioned the the core reason that profilers exist: We write code in high-level languages which get converted to machine language (CPU Operation Codes). A profiler can tell you that your code which is only 1 line (of high-level language) actually takes 5 CPU operations to complete. That part isn't actually obvious, because we write code at one layer and most people who haven't written assembly don't really understand this. Mostly you get lucky that the high-level languages and built in compilers optimize even very badly written high-level language into a smaller number of CPU operations. They do so much work these days, your code may not even be represented the way you think it is by the time it gets to the CPU. So, unless you are saying you can turn your high-level language into CPU operations in your head, you can still write code you think will perform well which actually somewhat inefficient when turned into OP Codes tha the CPU actually runs. That's where a profiler can come in handy. You can see what your code really does to the poor little processor. One of the best and easiest to use profilers is in ICSHarpCode's SharpDev Studio. Try out the IDE (Integrated Dev Environment) and I think you'll be amazed.SharpDev Studio - Open Source & Free [^] Hopefully I've provided some food for thought.
Nope. I can't convert C# to ASM in my head :). A lot of the performance issues I've resolved over the years, are just bad designs or code that's doing redundant work. One thing that another responder pointed out is that in the "real world" (non gaming :)), nobody is going to appreciate you shaving off a 100ms or 250ms or even 1000ms or even a second or two. However, in gaming where people get off to frame rate numbers, I can see how squeezing every little ms out of your code would be useful. I used to work on a project where the end goal was to process 4 BILLION records. One day I was optimizing some code and my boss yelled at me for wasting my time. I simply brought up my calculator and calculated 4,000,000,000 / 3600000 = 1111.11 hrs / 24 = 46 days for him and pointed out that cutting out a miniscule 1ms per record would save 46 CPU days on the project. He said "Oh" and walked away. Lol. I ended up shaving off a few MINUTES per record fairly easily.
-
Is the issue in the WPF app or in the WCF service? So, you have a WPF app for instance, that has a lot of code in its own right, and it gets its data via WCF service. Is the performance degradation in the WPF app or in the WCF service? Well, you can tell if it is the WCF service if the getter methods are showing longer than usual turn a rounds. It can point you in the right direction, and sometimes at the actual method. You usually use a profiler in big to enterprise level solutions. Using them on one method is a little lame, IMHO.
If the app involves database calls or WCF calls, I *ALWAYS* start my performance analysis by timing those calls :). I didn't mean to use them on one method specifically, but classes where the guy was trying to be all OO and a call into the entry point method ends up calling 50 other methods in a dozen other classes. I recently worked on some code like that lol. I dunno, I guess once I understand the general workflow, its fairly easy to get an idea of where the bottleneck would be (like WCF or database calls). I didn't bother fixing all his OO gone wrong code because some quick timing indicated that the majority of the time was due to calling into a 3rd party component 3 or 4 times PER out method call (and recreating that 3rd party object every time). LOL. Yeah, I could save some more time by fixing the guys mess, but that optimization wasn't really worth it since I already cut the call down from like 4 seconds to about 1 second. The rest of the fix wouldn't even be noticeable except in a high volume environment which this particular app wasn't really.