|
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.
|
|
|
|
|
Would like to mention here that depending on what you are doing to time the code, that a good profiler will show you automatically. it will point out graphically where the slow code is. No need to time. It will show you how much time is spent in exact portions of the code. The SharpDev profiler is amazine because it creates these very cool graphics which are concentric circles of the method calls, then inside those calls the calls the user calls that are made then finally the method may hit some system APIs and spend time in those DLLs and it shows you how much time is spent as a part of the entire method call. It is amazing and easy to use and it provides a very cool view of the code.
|
|
|
|
|
I did recently try out the Jet Brains profiler on that block of code that did the dictionary tuple lookup just for fun to see if profilers have improved since I last used them. It showed that my bottleneck was in GetHashCode(). That was identified as my #1 application hot-spot. The method that actually did the dictionary lookup was ranked almost dead last. That's a major profiler failure in my book. It didn't point me anywhere close to the right place. I messed around with the profiler for about half an hour trying various options to try to get it to show me the call tree that was at fault, but it didn't seem possible. Maybe it is and I just didn't set it up correctly. Like I said, I only spent about half an hour on it.
However, to be fair, I guess GetHashCode() *was* the ultimate method at fault, but none of the views in Jet Brains indicated that it was from the dictionary lookup and because I wasn't seeing call trees, if I didn't know what was going on, I probably would have never connected the two.
Probably the top 10 methods identified were internal .NET methods like GetHashCode() that really had nothing to do with figuring out the performance issue. Since it isn't really GetHashCode() that's the problem, but using a tuple in a dictionary is. The profiler also ranked TryGetValue as pretty low, so there was no indication that that method was calling GetHashCode() so much.
|
|
|
|
|
Your point is much clearer, and more powerfully expressed ... to me ... with this excellently written personal example.
thanks, Bill
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
|
|
|
|
|
Yes, but before I do, your original email opens up a bigger issue, I think. To demonstrate, let me ask:
Does anybody really use a debugger? You see, I think that any real software engineer should be able to write bug-free code and if looking at someone else's code, should be able to identify the bugs in a fairly straight forward process.
Pretty silly, right?
Of course this is tonge-in-cheek, but the point is that a profiler is a tool that has a place in the engineer's toolbox. By asking the question in a way that belittles the use of the tool, it seems the results of the answers will be biased, or at least the interpretation of the results will be.
(Full disclosure: Maybe there are a few who are so good they can optimize their code without a profiler, but I have learned the hard way that I am not one of those - I also used to believe profilers are for the weak.)
Engineers use tools. Engineers use data from experiments to test their products and, maybe, improve them. Ignoring a tool doesn't make sense to me.
I agree that profilers can be hard to use and produce a lot of noise, but using a lathe is hard, too, until you understand how to get good results from it. A profiler is not the primary tool, to be sure, but there are cases where it can be Indispensable (and has been to me). Here are where I think it makes a lot of sense:
1) Education: How does one get experienced in performance analysis and tuning with C#. And how to we know we are right? Sure, moving the invarient out of the loop make it run faster, but are there other things we could/should have done, as well? Profilers are a great way to learn where the bottlenecks are, especially when working with a new language or in a new environment. One line of code taking 85% of my runtime? How do I know it's that one? (Linq is an easy target, but what about your enum example? How do you know the first time?) I've had experiences similar to yours where I see something obviously bad and let the designer know only to be told "no way it's my problem"; When I show them profiling output proving they are the problem, they start to listen. Data are powerful things!
2) Real-time systems: I think much of the discussion on this thread has been about business-logic type applications. Large databases, searching, etc. But what if you are building a real-time processing system with streaming data in one thread, real-time analysis/processing in another and real-time display in a third (and it's actually much more complicated that that in real life as those threads are really collections of threads, possibly). I live in this world and I can tell you that I use a profiler before my final build (often many times, but certainly once!) to see how much slack I have. That is, where do I have performance issues that are close to being a problem. For those are the ones that may bite me in real-world use. My stopwatch tells me I'm OK, but I'm not. (Concrete example, I need to process 100 frames of data per second. I profile the code and find my main processing loop takes 0.009 ms. So I'm good, right? Well what happens if something else is running on the same machine, taking cycles away from me? I want to look at that function to squeeze out more performance if I can. And each change I make can be profiled to see if what I did really was an improvement or not and by how much. Some performance improvements require tricky code or code that's harder to maintain but provide very little real-world improvement; I stay away unless I really need every microsecond. I want to know, however, not just optimize until I can't any longer... and, yes, I've gone so far as to write in-line assembly code where I needed to! But I don't want to go there in my first pass of optimization.
3) Proving to a component manufacturer that their component is the problem. I've been here, also. I have a DLL from a hardware manufacturer that is causing a problem and I can prove it by getting accurate timings of how long some of their calls take. Yes, simple timer calls can be used for this, as well, but when I'm calling several dozen such functions, running the profiler can give me all the timings, quickly, and I am not modifying my code to do so.
4) Finding bugs. Yes! Similar to #2, actually. Imagine you have a program that meets the spec in terms of performance. So you ship. But you have one section of code that calls a function multiple times for no good reason. This is poor programming, but because it's done in multiple threads or in various methods that are not obviously related so it's hard to spot. The profiler can show that CheckStatus (for example) is being called a lot. You may look at to why this is and could fix what is currently (or soon to be) a bug in logic. If you are running on a system where battery life is important, then I consider this a bug.
I know you may not be convinced, and that's OK. I do 100% agree that understanding what you are doing, thinking and analyzing code FIRST is very important, but I don't think it's enough for most people.
I think this is a great discussion for opening up these potential issues.
Thanks!
|
|
|
|
|
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.
|
|
|
|
|
You are right though. There is so much sloppy code out there in the business world that your solid list you mentioned in your original post will make amazing differences in the code.
That's why no one uses profilers any more.  Half the coders are too busy out there blithely creating sloppy code and the other half are too busy out there applying solid principles cleaning it up.
|
|
|
|
|
Yes a profiler can't always get you the stats you need. Like others said, they are useful for finding hotspots in large distributed applications. For example I worked on a large web based CRM system that had randomly had extremely slow page render times. The whole system used DataSets as core data objects that were associated with classes defined in C# code that was stored in the database and dynamically compiled.
Now, I could have gone in and manually instrumented several hundreds of methods and objects, but using a profiler I was able to find the slow spots in several of the subsystems including the process of compiling the data objects. It took a little experimentation to find out which of several approaches was fast enough. The worst offender ended up being really inefficient code in the site navigation that involved a bad caching implementation.
I'm skipping around to your last example. A memory profiler will find that issue pretty quickly, in addition you will have a significant amount of time in garbage collection when you look at performance counters. I also like to instrument my code with custom performance counters so I can monitor it in production easily.
Ok, the highest performance C# app I worked on was a click scoring web service that took web server log lines and had to return a score in 100ms or less. It peaked out at about 6,000 scores per second averaging less than 1ms average response time. The entire first stage involved mapping strings to ids using Dictionary<string, int=""> objects. Then there were a number of shared statistics that were maintained based on those integer lookups. Several hundred rules were run on all that computed data. That was combined with a naive bayes classifer, and the statistics were updated with the results of the scoring, and the score was returned to the client.
The first versions loaded data as needed, but eventually everything was hugely sped up by loading the entire database in memory as the first step and then generating all the ids in the client. Also writing data out to the database was done with sql batch update objects which out perform any kind of stored procedures by wide margins. But even then, stored procedures haven't been faster than inline sql for years.
Micro-optimization like you are talking about can get you a long ways, but at some point secondary effects like garbage collection, memory paging, working set management, cache lines, etc. are going to become issues especially when you are working with something like a 16 Gigabyte process size with .net. At that point you have to look at more global 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.
Unfortunately, while there are millions of programmers, only a few have the analytic skills that Jon Skeet ... and, presumably, you ? ... have: [^].
To the rarer programmer who has "got down" in the plumbing, and studied the internal behavior of every operator in their language, and the structure of its framework, carried out timing experiments, etc. : I salute you !
cheers, Bill
“I have diligently numbered the days of pure and genuine happiness which have fallen to my lot: They amount to 14.” Abd-Ar Rahman III, Caliph of Cordoba, circa 950CE.
|
|
|
|
|
SledgeHammer01 wrote: look at a block of code for a few minutes and instantly identify why it's slow
I hate to destroy your self confidence, but some code is work just perfectly with input A and perform terribly with input B (see compression algorithms), so looking at the code and even understanding it means nothing without the real-time environment...
SledgeHammer01 wrote: maybe it's just a talent
The word you looking for is neglection me think...
SledgeHammer01 wrote: from my limited experience with profilers
Better learn profilesr (how to use and interpret its output) and after that we will hear you again...
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
