|
Eggbert Bartholomew Bligh wrote: Anyone else notice?
No
Within you lies the power for good - Use it!
|
|
|
|
|
Try the ones on the right.
|
|
|
|
|
If you've left the website why do you care what they have or don't have?
|
|
|
|
|
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 should know what parts of it are slow.
Also, from my limited experience with profilers, they are more of a waste of time then good. Let's say I have this:
Dictionary<Tuple<string, object>> dict;
and then I have some highly trafficked code that does:
if (dict.TryGetValue(new Tuple<string, object>("someString", 5), out result))
{
}
that's going to be really slow. A profiler is going to show you that 99% of the run time was spent in GetHashCode() and because you don't know how to think without a profiler, you'll be clueless as to what the real problem is. Which is:
1) you're new'ing up an object on every lookup
2) you should always use a simple native object as your dictionary key since compound objects are very expensive to hash (stay away from strings and guids as well).
Thoughts?
|
|
|
|
|
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
|
|
|
|
|
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. 
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
|
|
|
|
|
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.
|
|
|
|
|
Well said. 
|
|
|
|
|
Always profile. ALWAYS.
string ret = string.Empty;
for (int i=0; (i < someLargeInt); i++) {
ret += AMethodThatReturnsAString (i);
}
return ret;
Compilers are smarter than you. This can be compiled into highly optimized code with loop unrolling and expression templates among other optimizations.
The rule of thumb is:
1) write simple, clear, expressive code.
2) profile
3) fix hotspots
|
|
|
|
|
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.
|
|
|
|
|
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
/ravi
|
|
|
|
|
+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.
|
|
|
|
|
It made me lol
|
|
|
|
|
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 
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.
|
|
|
|
|
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.
|
|
|
|
|
Much worse is when two or more threads keep each other waiting, but the synchronization is needed. For example a thread that reads input from devices and inserts the data as messages into a queue for the UI. Obviously, the UI threads frequently are going to check the queue for new messages and this access must be synchronized. If the threads lock each other out too frequently, you will have to come up with something more clever than a simple queue to eliminate the need for synchronization.
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.
|
|
|
|
|
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... .
|
|
|
|
|
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.
|
|
|
|
|
Then don't use a profiler.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
