Performance Analysis Tools

Just finished listening to an excellent podcast. The show is called Deep Fried Bytes. Since I live in Atlanta, I couldn't resist.

They caught up with Rico Mariani, a long time performance guru at Microsoft, who blessed them with about 40mins of excellent advice.

The things that really struck a chord with me were:

Start off with broad-brush tools. Task Manager (is it IO? Or CPU?) followed by Perfmon followed by Profiling, in that order!

Being good at performance means you'll be wrong 19 times out of 20. So get really good at discarding dead ends quickly.

He mentioned a suite of tools called xPerf that I hadn't heard of, will have to check it out.

I can't wait to put this to use. TaskManager and PerfMon - these are low-hanging fruit. Everyone's used them at one point or another. ESPECIALLY the .net specific counters in PerfMon.

Visual Studio 2005 debugger

I can't help but praise the Visual Studio 2005 debugger.  The new browsable tooltips that allow you to quickly drill-down into an object in the current context is amazing.  The Autos and Locals windows are old standby's but, for me at least, I always seem to have to resize the column divider between the variable and it's value.

 

Sometimes the value is a long string, in which case there's never enough room because Autos, Locals and Watches are on the bottom left while the Call Stack, Immediate window, output, Threads, Processes and Memory are on the bottom right.  Maybe I should merge them all into a single window - unfortunately that would mean I'd lose context when switch frames on the call stack (context being the Autos window).  Will have to consider this more later.

 

With the browsable tooltips, if the screen is wide enough, then there's enough space because they automatically resize themselves.  WOOHOO!

 

The only thing that I'd add is a way to copy a string literal in it's unescaped form.  I often find myself copying a long path (usually in the temp folder - on XP this is usually something pathologically long like c:\documents and settings\firstname.lastname\local settings\temp\...., thank goodness Vista shortened this up) into a text editor to examine the contents of a file.  Fortunately ultraedit, imho the coolest editor on the planet, ignores the double-backslashed paths (or perhaps the win32 function it passes the path through ignores them).  So maybe this isn't really a problem but I had to have at least one gripe in this post so there it is.

 

Another gripe is the way the debugger deals with attaching to multiple processes.  The concept is very cool, especially if you're porting an app, but when I break into 1 process the other is paused!  Not exactly what I intended.  Easily remedied by attaching from another instance of Visual Studio.

Floating Point numbers and User Input

Computers can store decimal numbers in a variety of ways. One of the most widely used formats is IEEE754 floating point numbers.

Floating point numbers are popular because hardware support (in the form of coprocessors or microcode) makes floating point arithmetic very fast.

The tradeoff when using floating point number is that they typically represent a decimal number inexactly. So .001 may be 0.001000002342... As long as the imprecision is beneath your level of concern this isn't a problem.

Of course, errors accumulate particularly during multiplication, so even if this lack of precision doesn't bother you today it might bother you tomorrow when you start doing lots of multiplication.

The other form, popularized in COBOL, is an exact decimal format. Unfortunately, as far as I know, there is no hardware support for exact decimal arithmetic. So it's done in software and is much slower than floating point arithmetic.

What's this got to do with input from the user?

I'm mulling over options for dealing with decimal numbers that are specified by the user (either directly or indirectly from a file). So far I'm settling on using exact decimals to accept user input and store it in files. My rationale is that the choice of internal representation isn't something the user should be bothered with. It's an artifact of the way this particular app (and most apps) handles decimal arithmetic. If floating point is really good enough, why bother frustrating the user by converting their 1.052 into 1.05200003333 when they see it?

Using xcopy to copy and rename at the same time

xcopy has so many wonderful options but I rarely use it in .bat files because I couldn't get it to copy and rename a file at the same time.  e.g., xcopy mike.old mike.new results in a prompt asking me if mike.new is a file or directory!

 

The /I switch doesn't help since it only applies if more than 1 file is specified as the source.

 

Found a way around this:

 

echo f | xcopy src.file dest.renamed.file

 

The prompt still appears but f is echoed to standard in and the copy proceeds.  I mainly use this in visual studio post-build events because the /f option makes it easier to track down build issues (e.g., a file is being copied to the wrong location).

 

 

Working on XP projects on a Vista x64 system

Regsvr32 must be run from an elevated command prompt.

 

Managed code that targets "Any CPU" will howl in agony should it attempt to interoperate with 32 bit DLLs (e.g., via RCW).  HRESULT 0x80040154.

 

Still getting what appears to be a failed ATL assert just before exiting the app - disappears as soon as it appears.

Visual Studio 2005 Isolated references

If a managed DLL uses an active x control via COM interop and the reference to the interop library is marked as Isolated (via properties) then an assembly manifest is generated.

 

I've found that this assembly manifest is unusable for managed applications that reference the managed class library.  It includes the underlying COM dll as a file element in the manifest but does not include it in a dependency element; perhaps it's implicit.  Instead, I've found that I have to include the underlying COM dll in a dependency element in the application manifest (app.exe.manifest) and leave it out of the managed dll entirely (e.g., no assembly manifest for the managed dll).