no compiler optimizations!
ZenRhapsody
Posts: 14
The fact that ANTS profiler disables compiler optimizations REALLY messes up my results!! (And I'm using the 14-day trial version)
I know certain sections of my code will be bottlenecks becuase they will be called a gazillion times. I have diligently worked to ensure (as well as can be) that usage will be in-lined in as many cases as possible.
Many are simple property values like the sample ComplexNumber.GetX and GetY. I've even gone to great pains to refactor code so that 80% of usage can be done in less than 32 bytes of IL so that it will inline. Something like
if (80% condition)
return simple*formula;
else
return DoTheHarderCalculation();
Now that I profile my application, low and behold, all the methods that I knew would have high hitcounts are the slowest! JIT optimization has been disabled.
So I cannot tell what really needs to be worked on, and when I do find something to work on, if my solutions involve inlining more code, I'll never see the result in my profile results.
Is there ANY way around this? Or anything in work to "fix" this missing feature? I realize allowing inline code will affect hitcount results, but shoudln't I have that option? even if you just flagged hitcount values in potentially inlined methods, that would be a HUGE service!
Inline code is a big part of optimizing code, so any valuable profiler tool should be able to accomodate it.
I know certain sections of my code will be bottlenecks becuase they will be called a gazillion times. I have diligently worked to ensure (as well as can be) that usage will be in-lined in as many cases as possible.
Many are simple property values like the sample ComplexNumber.GetX and GetY. I've even gone to great pains to refactor code so that 80% of usage can be done in less than 32 bytes of IL so that it will inline. Something like
if (80% condition)
return simple*formula;
else
return DoTheHarderCalculation();
Now that I profile my application, low and behold, all the methods that I knew would have high hitcounts are the slowest! JIT optimization has been disabled.
So I cannot tell what really needs to be worked on, and when I do find something to work on, if my solutions involve inlining more code, I'll never see the result in my profile results.
Is there ANY way around this? Or anything in work to "fix" this missing feature? I realize allowing inline code will affect hitcount results, but shoudln't I have that option? even if you just flagged hitcount values in potentially inlined methods, that would be a HUGE service!
Inline code is a big part of optimizing code, so any valuable profiler tool should be able to accomodate it.
Comments
ANTS Profiler cannot work correctly with optimizations such as code inlining because of its' design. I can't say if it's possible to allow optimizations like this in the CLR and still allow ANTS Profiler to function properly.
I'm sorry, but there isn't anything I can suggest to work around and there is more than likely never going to be a way for ANTS Profiler to support this.
Thanks for the upfront reply.
I understand JIT compiler optimizations could wreck your ability to profile effectively and reconcile back to the source code.
However, this is a severe limitation on the usefulness of this product for analyzing a large scale commercial application.
Obviously, I do not know the details of your profiler design (or of the .NET compilers even), so I may now ask some stupid qustions.
If my functions that are likely to be inlined are isolated to a separate DLL assembly with a separate namespace, could they be completely excluded from the profiling process and allowed to inline compile into the assemblies being profiled? I tried something like that by excluding a class name, but I didn't see any difference (though I didn't read the help closely, so I may have done it wrong..)
Again, I don't know how you work, but it would be great to me to mark individual methods as 'not profiled'. Calls into these methods would be treated like calls into .NET native methods, where it's just a line of code instead of a function call.
Enough of the negative...
Except for the inlining problem, I love the product. The usability and presentation are great. I was getting some useful information out of the results less than 15 minutes after downloading the trial version. You've done a great job with presenting the results!
Thanks for your comments. If it ever becomes possible to support compiler optimizations at some future date, we'll make sure to re-evaluate it. It is true that when the profiling interface is enabled, programs can behave quite differently and this is something that would be great to avoid!
"However, if you delete the pdb file ANTS Profiler will only time methods. "
if I do this, does ANTS still disable inline compile?
I'm not sure what the context of this quote is. I'm assuming he's talking about the ability to have line-level timings, but only if the source code is available.
I'm afraid that we disable inlining globally when we profile performance. We decided to do this to ensure that we get complete code coverage. However, it is really only a setting that is provided by the CLR. We will look into having an option to control it in the next version.
Sorry for the current incovenience,
Tom Harris
Red Gate Software
Thanks for the reply. I would really like to see you add the ability to enable code inlining.
In my evaluation tests of your product, 3 of the top 10 slowest methods would be inlined, and 2 more are in the top 10 because they use the methods that would be inlined. A competing product removes these correctly and with the correct information, I was able to determine that one of the methods could use further tuning even with the inline compile. Your analysis loses this information.
However, I am using your hit count and line level timings quite a bit.
I may have to loosen the purse strings to purchase both products!