Author: alski

Sometimes you don’t get much credit except in the debug logs

I recently re-engineered my primary responsibility at work and when asked for a marketing spin on the work I said that ExcelRTD could now update 3 million cells per second in Excel via IRTDServer. This was dismissed as being over confident and I must admit the biggest problem is that although I can get the info to Excel in the time, Excel will then sit for a long time, say 5–15 seconds digesting it. So the only real way I can show this is by looking at the Debug output, where I time the entire RefreshData() operation. i.e.

public Array RefreshData(ref int topicCount)
{
   Win32Extra.HiPerfTimer timer = new Win32Extra.HiPerfTimer();
   timer.Start();

   try
   {
      Array result;
      …
   }
   finally
   {
      timer.Stop();
      Debug.WriteLine(“RefreshData @” +DateTime.Now.ToLongTimeString()
         +“, Count=”+topicCount.ToString()
         +“, in |”+timer.Duration +“| ms”);
      return result;
   }
}

}

So that of course means that my values show the whole time I can influence. Unfortunately they also time while the process is switched out, so heres my results from opening a huge sheet. The good are in Bold and the bad are Italicised.

Check: 1 sec was 991.611224331584ms
RefreshData @11:37:18, Count=7, in |11.0257029873909| ms
RefreshData @11:37:26, Count=5861, in |77.4053685594119| ms
RefreshData @11:37:53, Count=1453, in |1.87537801592102| ms
RefreshData @11:37:55, Count=1649, in |3.066311500484| ms
RefreshData @11:37:57, Count=218, in |0.112025411050846| ms
RefreshData @12:02:49, Count=44672, in |21378.2092416774| ms
RefreshData @12:02:59, Count=0, in |442.494506983429| ms
RefreshData @12:03:01, Count=84656, in |440.760208350503| ms
RefreshData @12:03:09, Count=0, in |0.0282158765988415| ms

Damn, the peak rate has dropped by a factor of four. Now its only 3/4 million per second. If only I could find out why? Oh well that’s the joy of working in multi-tasking operating systems.

Recovered Post: Visual Studio Assembly Cache

All,

In the various builds we all have the ExcelRTD project which has always seemed to work magically when it comes to installing via COM itself for debug purposes. Some not so good news, this is likely to break when you start moving to the next version with Bonds.

 

Monitoring a Debug Run

Following a lengthy session with FileMon I discovered that the IExcelRTD server seemed to not be getting its dll’s from the GAC or the local directory but from C:\Documents and Settings\…\Local Settings\Application Data\assembly\dl2\…\…\…\… [actually GWVO70ZL.PCT\NK9B96Q2.MNJ\0da889d1\4c31828b_0a62c501]. So like any careful developer, I deleted the whole tree of files below dl2. Rebuilding the project installs the dll and dependencies into various directories within this tree (the first two parts of the path stayed static).

 

How “Register for Com” seems to work

I will therefore make the several leaps of intuition to come up with the following scenario. When a project is compiled with Register for Com checked then it builds the Dlls as normal and copies it and its dependencies to the output directory (usually bin/Debug). The TLB is also generated and placed in the output directory. Now for the fun bit, each dll is copied into the C:\Documents and Settings\…\Local Settings\Application Data\assembly\dl2\[xxx\xxx]\[yyy\yyy] path where [xxx\xxx] is common to all dlls, but [yyy\yyy] is specific to each. Along with each dll Visual Studio also places the .pdb  and an __AssemblyInfo__.ini file.

e.g.

[AssemblyInfo]

Signature=….

MVID=….

URL=file:///C:/vss/xxx V2.1/xxx.Bank/ExcelRTDOffice11/bin/Debug/xxx.xxx.Data.DLL

DisplayName=xxx.xxx.Data, Version=2.0.0.1, Culture=neutral, PublicKeyToken=e64fdb2f….d84

 

In another [yyy\yyy] a copy of Microsoft.VSDesigner.DLL 7.10.3077.0 is placed, and the whole lot of dlls in \[xxx\xxx]\[yyy\yyy] are registered. Finally the TLB is used to specify the COM part.

 

Recovered Post: Performance Counters

Intro

At work I have a set of server processes that run and process emails. Once processed then an event is set out to our clients informing them that the new data for the primary key is available. Synchronoulsy. This of course has the effect that every client machine has to read from the server to update before the next email can be parsed, and should a client stop responding then the whole process hangs.

So my recent bug fix was to separate the parsing of the emails from the Notification of the clients. I used a Queue wrapped in a Thread Safe manner, and added into a singleton class. The add method then kicks off a thread (should one not already exist) which then starts dispatching the messages out to the clients.

Now what this has do with instrumentation is that the queue needs monitoring so that you can see how far the dispatch of the clients is getting behind the parsing of the emails. Now that is where the Performance Counter classes come in

http://msdn.microsoft.com/…/vbwlkEnumeratingPerformanceCountersOnServerStepByStep.asp or ms-help://…/vbtskcreatingcustomperformancecounters.htm

Things I found

Well I’ve had issues with loosing all Performance counters (yes that includes System counters as well) on two machines.

I also found that it was much easier to work with Instances than without.

Remote debugging

These are the steps

1. Install Studio (or a subset see link)
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/vsdebug/html/vctskinstallingremotedebugmonitor.htm

2. Ensure that the you are added to the ‘Debugger users’ group on the local machine.
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003FEB.1033/vsdebug/html/vxtskinstallingdcom.htm

3. Apply the following reg key if you are not logging on to both boxes as the same user.

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Machine Debug Manager]
"AllowLaunchAsOtherUser"=dword:00000001