all groups > dotnet performance > july 2006 >
You're in the

dotnet performance

group:

Profiling and inlining


Profiling and inlining ti NO[at]SPAM rapidis.com
7/19/2006 12:46:11 PM
dotnet performance:
Does anyone know of a profiler which will allow me to analyze the
performance of jit'ed assemblies taking into account optimization like
inlining?

I've tried the profiler built in to Visual Studio 2005 and I've tried
IBM Rational's Quantify. Both of them seem to somehow cause the JIT not
to do inlining (it probably doesn't do any optimizations).

Consequently when I look over the results and try to identify
bottlenecks (in a rather complex and long-running algorithm), the
results from both tools are completely skewed by the fact that a few
small accessor functions, which are called very frequently are not
inlined.

Right now I'm left with temporarily manually inlining these functions
just for the sake of running the profiler, and there might be many more
missing optimizations that still skews the picture after that.

I'm interested in any advice that might help me: other (better)
profilers, workarounds, etc.

Thanks.
Re: Profiling and inlining Barry Kelly
7/19/2006 11:06:38 PM
[quoted text, click to view]

Are you doing sample-based profiling and staying well away from
instrumentation-based profiling?

-- Barry

--
Re: Profiling and inlining ti NO[at]SPAM rapidis.com
7/20/2006 11:50:04 AM
I've done both. Though mostly instrumetation-based, since I was
interested in measures for which specific lines in a few big functions
were most costly. Quantify does this easily, and I don't think VS
2005's profiler does it. And it seems to me that Quantify only does
instrumetation based profiling. But I might be wrong.

Why are you suggesting that I stay away from instrumentation
based-profiling?

Thomas

[quoted text, click to view]
Re: Profiling and inlining ti NO[at]SPAM rapidis.com
7/20/2006 11:51:17 AM
I've done both. Though mostly instrumetation-based, since I was
interested in measures for which specific lines in a few big functions
were most costly. Quantify does this easily, and I don't think VS
2005's profiler does it. And it seems to me that Quantify only does
instrumetation based profiling. But I might be wrong.

Why are you suggesting that I stay away from instrumentation
based-profiling?

Thomas

[quoted text, click to view]
Re: Profiling and inlining ti NO[at]SPAM rapidis.com
7/20/2006 12:10:53 PM
A related issue:

I'm trying to figure out what the JIT will inline at what it won't. 2
questions:

1. Will the JIT inline this function? (from actual software):

public int GetEdgeCostIndex(bool isConnector, bool isForward)
{
if (isConnector)
{
if (isForward)
return ForwardConnectorIndex;
else
return BackwardConnectorIndex;
}
else
{
if (isForward)
return ForwardLinkIndex;
else
return BackwardLinkIndex;
}
}

2. How do I get CorDbg to show dissaembly for the JIT's optimized code?
I tried the sample program below. The TestMethod() function should a be
prime candidate for inlining, but cordbg doesn't show that.

class Program
{
static void Main(string[] args)
{
for (int i = 0; i < 1000000; i++)
Program.TestMethod();

System.Console.WriteLine("x");
}
public static void TestMethod()
{
return;
}
}

Below is seen a session in cordbg with a release build of the above
program. Note that the function is not inlined. What gives??

Microsoft (R) Common Language Runtime Test Debugger Shell Version
2.0.50727.42 (RTM.050727-4200)
Copyright (C) Microsoft Corporation. All rights reserved.

(cordbg) mode JitOptimizations 1
JIT's will produce optimized code


(cordbg) run csinlined.exe
Process 3856/0xf10 created.
Warning: couldn't load symbols for
C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll
[thread 0x7b8] Thread created.

007: for (int i = 0; i < 1000000; i++)
(cordbg) dis 100
Function CsInlined.Program.Main (code starts at 0x11a9ba8).
Offsets are relative to function start.
[0000] push esi
[0001] push eax
[0002] mov dword ptr [esp],ecx
[0005] cmp dword ptr ds:[00962DDCh],0
[000c] je 00000007
[000e] call 78EE8748
[0013] xor esi,esi
*[0015] xor esi,esi
[0017] nop
[0018] jmp 00000009
[001a] call dword ptr ds:[00963044h]
[0020] inc esi
[0021] cmp esi,0F4240h
[0027] jl FFFFFFF3
[0029] mov ecx,dword ptr ds:[02302098h]
[002f] call dword ptr ds:[011D1364h]
[0035] nop
[0036] pop ecx
[0037] pop esi
[0038] ret
(cordbg) ss
[0021] cmp esi,0F4240h
(cordbg) ss
[0027] jl FFFFFFF3
(cordbg) ss
[001a] call dword ptr ds:[00963044h]
(cordbg) ss
[000e] nop
(cordbg) dis 100
Function CsInlined.Program.TestMethod (code starts at 0x11a9bf8).
Offsets are relative to function start.
[0000] cmp dword ptr ds:[00962DDCh],0
[0007] je 00000007
[0009] call 78EE86FD
*[000e] nop
[000f] ret
(cordbg)
Re: Profiling and inlining ti NO[at]SPAM rapidis.com
7/20/2006 5:24:44 PM
Thanks for the advice. I didn't realize that instrumentation was
unreliable for timing. I'll proceed with the sampling in VSTE.

In that context, do you know of a good way to get a brakedown of which
statements in a big function are the time consuming ones? The Profiler
in VSTE will only tell me the time for the function itself.

[quoted text, click to view]
Re: Profiling and inlining ti NO[at]SPAM rapidis.com
7/20/2006 5:31:01 PM
Once again, Thanks for valuable advice. I have used windbg before, but
not with SOS, so I didn't think of it for this. I'll go right ahead and
use the method you outlined on my application to see if the JITer will
inline my GetEdgeCostIndex function.

It's odd though, I spent hours today trying to get cordbg to show the
optimized disassembly without any sucess, since I've that method
recommended in several other places.

Thanks again.

[quoted text, click to view]
Re: Profiling and inlining Barry Kelly
7/20/2006 11:02:07 PM
[quoted text, click to view]

Instrumentation can't reliably monitor time performance, since it
changes the code. For example, it typically prevents inlining. Usually,
a sampling profiler is needed, unless you're trying to track down a
problem that shows a method is being called more often than you think it
should be.

[quoted text, click to view]

VS 2005 Team Edition (I last looked in Beta 2, I only have Pro) appears
to have two profilers, one for instrumentation (best for memory
profiling) and another for sampling (best for time profiling).

-- Barry

--
Re: Profiling and inlining Barry Kelly
7/20/2006 11:20:33 PM
[quoted text, click to view]

It might, but then, it might not.

[quoted text, click to view]

You should probably use WinDbg and SOS. Typically, to check out compiled
code, I stick a native breakpoint in an application (be sure it breaks
after the code has been called at least once, so that it has been
JITted) and run it under WinDbg until it breaks. I then do:

..load sos
!name2ee Test.exe Program.Main // or whatever
!u <methodAddressFromName2EE>

For my native breakpoints, I typically use WinDbg to break in WriteFile
(bp kernel32!WriteFile), and is typically triggered by a console write.
Alternatively, you can PInvoke to DebugBreak in kernel32.dll.

[quoted text, click to view]

I built this program with optimizations enabled (/optimize+) and I
debugged it with WinDbg. Here's a reduced-size dump:

---8<---
0:000> bp kernel32!WriteFile

0:000> g

Breakpoint 0 hit

0:000> .load sos

0:000> !name2ee Test.exe Program.Main
Module: 00922c14 (Test.exe)
Token: 0x06000001
MethodDesc: 00922fd8
Name: Program.Main(System.String[])
JITTED Code Address: 00ca0070

0:000> !u 00ca0070
Normal JIT generated code
Program.Main(System.String[])
Begin 00ca0070, size 28
[quoted text, click to view]
00ca0077 750a jne 00ca0083
00ca0079 b901000000 mov ecx,1
00ca007e e889d76a78 call mscorlib_ni+0x28d80c (7934d80c)
(System.Console.InitializeStdOutError(Boolean), mdToken: 0600070f)
00ca0083 8b0d84102802 mov ecx,dword ptr ds:[2281084h]
00ca0089 8b153c302802 mov edx,dword ptr ds:[228303Ch]
00ca008f 8b01 mov eax,dword ptr [ecx]
00ca0091 ff90d8000000 call dword ptr [eax+0D8h]
00ca0097 c3 ret
--->8---

You can see here that the code has been completely removed, the loop
too.

-- Barry

--
Re: Profiling and inlining Barry Kelly
7/21/2006 1:56:56 AM
[quoted text, click to view]

Apart from breaking it into separate functions (which is often a good
practice anyway), no.

-- Barry

--
Re: Profiling and inlining Greg Young
7/21/2006 2:41:43 PM
[quoted text, click to view]

You can do this right in Visual Studio ..

I wrote up some quick instructions on my blog
http://codebetter.com/blogs/gregyoung/archive/2006/06/09/146298.aspx

Cheers,

Greg Young
MVP - C#
http://codebetter.com/blogs/gregyoung

[quoted text, click to view]

AddThis Social Bookmark Button