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've done both, and yes, using your noggin to choose a better algorithm wins over using a profiler every time. The profiler can only tell you how to make your bubble sort run faster, it can't tell you to choose to implement a quicksort instead.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
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 agree that when analyzing a simple block of code, a profiler is probably overkill. I've used a profiler in the past for projects written by multiple people and that have a lot of other process interactions and data coming in at different rates etc. Profiler stats speak louder and less personally than you going and analyzing other peoples code and giving them the same feedback :-)
-
I agree that when analyzing a simple block of code, a profiler is probably overkill. I've used a profiler in the past for projects written by multiple people and that have a lot of other process interactions and data coming in at different rates etc. Profiler stats speak louder and less personally than you going and analyzing other peoples code and giving them the same feedback :-)
If I was asked to review a co-workers code and he wasn't interested in my feedback unless I produced profiler outputs, charts, stats, graphs and 5 page PDF presentations, I'd consider that co-worker a douche and a waste of time and go work on something else. If my boss came and asked if I had a chance to review Bob's code, I'd simply say "Yup. I located the issue, but Bob wasn't interested in my feedback, so I went back to working on X.". That's not a theoretical "What would you do?" :). I've done that several times over my career and it generally ended very badly. For Bob. I was a newb at a job like on my 2nd or 3rd day and I overhead Bob talking with his boss at the next cubicle about an issue that Bob had been working on for 2 weeks with no success. I was familiar with the issue since I was very strong in that area. So I politely went up to them and said "Excuse me, I couldn't help but hearing about the issue. Not to interupt or anything, but I'm certain your issue could be resolved by doing X as I have run into that issue before and am very familiar with it." Bob pretty much tore me a new one in front of the boss and said that I had no clue what I was talking about as this was my 2nd day on the job and that I should go back to surfing the net or whatever it was he said along those lines. Turned out I was 100% spot on :) and Bob was fired for his unprofessionalism :).
-
Any reason why parametrized SQL code would be slower than a stored procedure? I mean, unless your statement is so big that the network overhead of sending it would be significant, a parametrized statement would have its execution plan cached by the server, same as the stored procedure. Of course it's a lot more interesting to get all the results you need in one statement instead of looping over every row and issuing a SQL statement for every row. Same goes for LDAP.
Additionally, using the stored procedure doesn't eliminate the parameterized SQL code -- so now you have two things that need to be profiled, by two different profilers.
-
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:
- don't inline SQL code, use stored procs
If you can inline SQL code, your DBA is an idiot for permitting you to do so. Of course that's the case in 85% (WAG) of the SQL environments out there. The only profiler I use is SQL's and yes, I use it to find slow performance code, but that's because I didn't write most of the code, so I don't know it. I haven't the faintest how to use a profiler to improve performance. To me all it's good for is to find code that could stand improvement.
-
If I was asked to review a co-workers code and he wasn't interested in my feedback unless I produced profiler outputs, charts, stats, graphs and 5 page PDF presentations, I'd consider that co-worker a douche and a waste of time and go work on something else. If my boss came and asked if I had a chance to review Bob's code, I'd simply say "Yup. I located the issue, but Bob wasn't interested in my feedback, so I went back to working on X.". That's not a theoretical "What would you do?" :). I've done that several times over my career and it generally ended very badly. For Bob. I was a newb at a job like on my 2nd or 3rd day and I overhead Bob talking with his boss at the next cubicle about an issue that Bob had been working on for 2 weeks with no success. I was familiar with the issue since I was very strong in that area. So I politely went up to them and said "Excuse me, I couldn't help but hearing about the issue. Not to interupt or anything, but I'm certain your issue could be resolved by doing X as I have run into that issue before and am very familiar with it." Bob pretty much tore me a new one in front of the boss and said that I had no clue what I was talking about as this was my 2nd day on the job and that I should go back to surfing the net or whatever it was he said along those lines. Turned out I was 100% spot on :) and Bob was fired for his unprofessionalism :).
I was surfing code to get a feel for what was being done. I was pleased with the naming conventions because I could tell what was going on just by reading the variable names. Then I read a bug because the code told me exactly what it was doing. Went to my manager, expecting to get my hand slapped for daring to read what was none of my business. Instead I was told it was built per specs. So I asked to see the specs. To my surprise I was given the specs. These were the most exacting specs I'd ever seen. I agreed that the code exactly matched the specs. The manager looked like she thought the subject was closed. Then I said, it's just too bad the specs are asking to have the code do something incorrectly. We ended up in the lab where I said this code should blow up with threading problems at times. The lab tech pipes up, and says they are having problems with code blowing up with threading problems. THEN the manager was willing to look at the math that immediately told me there was a problem. I finally was able to prove that if the maximum thread count was 100 and the step count was 20, the current count was 100, it would ask for 20 more threads, when it was 120, it would ask for 20 more. It would only stop asked for more threads when you reached 121. I can't remember which but setting a + to - or vs versa would have solved the problem or switching the side that added or subtracted the step count would be another way to fix it.
-
I was surfing code to get a feel for what was being done. I was pleased with the naming conventions because I could tell what was going on just by reading the variable names. Then I read a bug because the code told me exactly what it was doing. Went to my manager, expecting to get my hand slapped for daring to read what was none of my business. Instead I was told it was built per specs. So I asked to see the specs. To my surprise I was given the specs. These were the most exacting specs I'd ever seen. I agreed that the code exactly matched the specs. The manager looked like she thought the subject was closed. Then I said, it's just too bad the specs are asking to have the code do something incorrectly. We ended up in the lab where I said this code should blow up with threading problems at times. The lab tech pipes up, and says they are having problems with code blowing up with threading problems. THEN the manager was willing to look at the math that immediately told me there was a problem. I finally was able to prove that if the maximum thread count was 100 and the step count was 20, the current count was 100, it would ask for 20 more threads, when it was 120, it would ask for 20 more. It would only stop asked for more threads when you reached 121. I can't remember which but setting a + to - or vs versa would have solved the problem or switching the side that added or subtracted the step count would be another way to fix it.
Did you also point out to your boss that it doesn't make any sense to have more threads then CPU cores? (or CPU cores x 2 if you turn on hyperthreading). Give or take... If you are banging 100 threads on a 4 core + hyperthreading (8 threads), you'll lose any performance gains from all the context switching :).
-
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
A profiler is a tool like anything else. It can sometimes expose inefficiencies that you never would have thought of, or other times be useless (e.g. you can't fix what is using most of the CPU time/memory without a significant redesign). A person's assumptions of what is and isn't efficient can also be flawed.. Even with an experienced developer, when it is based on past observations, which could dramatically change with a single new release of your runtime/external libraries/compiler. The same could be said about using a debugger vs. just adding debug logging. With a debugger you may be wasting a lot of time tediously stepping through the code execution, instead of letting it run and simply browsing the debug log to narrow down the problem. But sometimes simple debug output isn't enough, and a debugger is required.
-
I've done both, and yes, using your noggin to choose a better algorithm wins over using a profiler every time. The profiler can only tell you how to make your bubble sort run faster, it can't tell you to choose to implement a quicksort instead.
We can program with only 1's, but if all you've got are zeros, you've got nothing.
The profiler can't tell you how to make your bubble sort faster, only that if you made it faster that would have a major impact on run time (for large data sets). It wouldn't tell you what methods to use to achieve this additional performance, but it would be able to help you understand how and why adding more code sped up the sort (because it executed each piece of code less often).
-
Did you also point out to your boss that it doesn't make any sense to have more threads then CPU cores? (or CPU cores x 2 if you turn on hyperthreading). Give or take... If you are banging 100 threads on a 4 core + hyperthreading (8 threads), you'll lose any performance gains from all the context switching :).
For CPU bound threads this is the case, but if threads are waiting on IO or get to sleep, this is not the case. More threads than cores can sometimes even be a winner for CPU intensive programs if physical memory is the bottle neck under some circumstances (swapping memory to disk is IO that might need to make a thread take a nap). It's nice when you can design for nearly 1-to-1 thread/core relationships, but it's often quicker (in terms of developer time) to mostly write all threads in a style similar to stand alone programs rather than to separate everything into queueable tasklets that don't sleep (they never sleep! but they do run to completion and often schedule a continuation tasklet to handle results of an IO operation or to start up after a given passage of time).