|
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)
|
|
|
|
|
|
SledgeHammer01 wrote: You couldn't use your profiler without the proper input either
That's profiler IS. Check your code in real-time environment. And if you believe that you can solve the issue by seeing the input, you never saw real input and never understood the issue!
I'm not questioning your powers of observation; I'm merely remarking upon the paradox of asking a masked man who he is. (V)
|
|
|
|
|
Many, many times. Both static and dynamic profiling is an important tool in enterprise development. Yes, your basic steps are useful in a single application, but when you move into a large distributed, multi user system simple code viewing doesn't cut the mustard any more. The time it takes to look through hundreds of methods and calculate which ones will be a problem under which conditions is waisted if you have a decent set of diagnostic tools at your hand.
Real example. I had a junior put together a piece of work. Simple service for validating the entry from a form. Now applying your logic above the code would check out fine. Performance was good on the test system and there were no obvious conflicts, data was being cached, look ups avoided, etc, etc, etc. The memory footprint was a pig, absolutely horrendous. And for each user the problem increased. We needed to pool resources, reduce cached data and in some places slowed down response times.
|
|
|
|
|
I also find this curious. "You didn't use a profile, did you" is a pretty common piece of bullshit that people sling. It's almost always perfectly obviously what the problem is, or that something will be a problem, without even running the code let along profiling it.
Basically what that comes down to is, if you do something stupid, it's going to suck. And preemptively not doing stupid sh*t is not "premature optimization".
Of course it's not always obvious. For example,
xor ecx, ecx
_benchloop:
lzcnt eax, edx
add ecx, 1
jnz _benchloop Why does this measure the latency of lzcnt, instead of its throughput? It doesn't look like it should do that, so in the original code that contained the "problem lzcnt", that problem gave me quite the chase. Initially I didn't even notice something was wrong.
No actual profiler was involved though.
|
|
|
|
|
They always just say "male, aged 18-35, who used to kick cats", so it's a waste of time even consulting them.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Good luck finding the most important bottle necks in applications of several millions lines of code without a profiler!  Hell, even in smaller applications I wouldn't even bother finding bottlenecks without a profiler. Why would you deny yourself a helpful tool?
Wout
|
|
|
|
|
wout de zeeuw wrote: Why would you deny yourself a helpful tool?
Because he thinks the tool sucks
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.
|
|
|
|
|
They do[^].
(sorry; it was just too easy)
Software Zen: delete this;
|
|
|
|
|
I find the idea of not being able to use every tool available to you is incredibly naive. Granted that you should be able to solve simple performance problems just by looking at them, but some problems are just too big and interwoven to solve like this. Also, it's not always just your code that you're profiling - don't forget that you can often identify problem areas in code that you're using that there might be alternatives to. So yes, I use profilers regularly. I use them because I'm aware enough to know I don't know everything and that there's always something new that I can learn.
|
|
|
|
|
>>> 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.
Are you serious!? Maybe for a single method or simple application, but for a complex application there's no way you can "just see it". Here's a simple real world example, recently I used a profiler to see where the bottleneck was in a web service which sits on top of 3 or 4 other layers (and I won't elaborate cause I'm keeping this simple). It turns out the bottleneck was in a piece of Microsoft code used within the ORM we use, so that was refactored to use a different method to do the same thing. No way you would have just seen that by looking, not least cause the code wasn't there to see.
I'd happily admit I also wouldn't be able to just see an issue in my own code some of the time. In the above example we're talking 1000s of lines spread over multiple assemblies, why would I bother trawling through all that when I can just use a profiler?
I was lucky enough to be able to test this for a single thread, good luck if you come across an issue that only occurs when you've got multiple threads involved.... 
The profiler is your friend.
PS. does this mean you never use SHOWPLAN/EXPLAIN either?
|
|
|
|
|
Absolutely I use a profiler. You're right that looking at code can often provide the answer, but when you're code base is several thousand lines of code split across multiple components using a profiler can at the very least help identify where the problem is.
It's also useful to spot things which might not be a problem with your code. Maybe a library you're using is doing something stupid, perhaps it's a little known feature of the .NET framework which is causing you problems. We recently had an issue with an older piece of software which was running into that, looking at the code would not have helped in the slightest but a profiler quickly sorted out where the problem was.
A profiler should be a part of any developers toolbox, fair enough that it shouldn't be the only solution to every problem, but it should be a tool that you are comfortable using and comfortable to know when to use.
Eagles may soar, but weasels don't get sucked into jet engines
|
|
|
|
|
Inline SQL works fine so long as your queries are parameterised.
|
|
|
|
|
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 rarely use profilers, but there are a few cases when even good programmers may have trouble seeing where code is slow. Sometimes there may be a library call which you think will be fast, but turns out to be slow. This could be due to system call(s) that take longer than the programmer realizes or due to the library function's algorithm working very differently than the programmer realized. We all make assumptions about things that sometimes aren't true. One very big issue is using something like using strlen(some_string) as a constant in a C program. Many programmers use that as though it is a constant in the compiler's mind, when it may not be (GCC has an __attribute__ that lets the compiler see that it is, but it's not standard). That's the kind of thing that could end up in a loop, possibly as part of the loop check, without many programmers realizing that it's a problem. While you might see that code, there are similar circumstances which are less obvious. These are often the results of invisible code introduced by compilers for languages higher than C. Overloaded operators, copy constructors, and destructors can all have much more impact on code than programmers realize. Knowing what kinds of things your language may hide is a good way to avoid these, but some things still slip through.
Other things that are easy to miss is how contentious locks, semaphores, mutexes, and other blocking operations are. These are difficult to figure out sometimes.
There are also times when you need to demonstrate to someone else where the bottle necks in code are. If your cocky junior programmer weren't your subordinate but rather your boss then the output of a profiler would be something that you could use to combat the cockiness. This is particularly useful when you get "Your code is slow! Fix it!" and you can come back with "This external code/hardware/whatever, which isn't under my control, is what is slow."
Another time when using a profiler would be very useful would be if there were disagreement or uncertainty over which of multiple parts of a program were responsible for the different amounts of the slowness. Maybe you need to prioritize the order in which these are addressed. For you or I it may be obvious that a section of code is slower than it has to be, but when comparing two suboptimal sections of code it is very often that eyeballs alone are not enough.
There are also times when a profiler can be used to find bugs that would take a lot of stepping in a debugger to locate.
|
|
|
|
|
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).
|
|
|
|
|
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 .
|
|
|
|
|
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 .
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
