What’s Going On Here?

I’m currently reading up on Performance Counters in .NET, and have been taking notes on the topic, so I can refer back later.

These are a series of links and facts that I found helped me understand the topic. Most of the information was available on MSDN, so the relevant links are included.

Some Links

Performance counters front page: http://msdn.microsoft.com/en-us/library/w8f5kw2e.aspx

Runtime Profiling: http://msdn.microsoft.com/en-gb/library/w4bz2147(v=vs.110).aspx

Overview

Performance counter can be used for both for reading and writing pre-defined or custom performance counters.

Reading an Existing or Pre-Defined System Counter

To use, simply instantiate an object, set CategoryName, CounterName, and, optionally, InstanceName and MachineName. and then call NextValue().

The following will get us some simple perf stats:

PerformanceCounter PC = new PerformanceCounter();
PC.CategoryName = "Process";
PC.CounterName = "Private Bytes";
PC.InstanceName = "Explorer";
Console.WriteLine(PC.NextValue().ToString());

Creating a Custom Counter.

You might want to create a custom performance counter, for example, you may choose to instrument the number of records returned from a query over time. We could expose this through a performance counter, and monitor it through Perfmon.

To write to a custom performance counter:

1. Create a new CounterCreationData class. We need:
   • Counter Name
   • Counter Help Text
   • Item from PerformanceCounterType enumeration
2. Create a CounterCreationDataCollection and add the CounterCreationData class to it.
3. Create a custom PerformanceCounterCategory counter using PerformanceCounterCategory.Create
   • Category Name
   • Category HelpText
   • Item from PerformanceCounterCategoryType enumeration
   • Our CounterCreationDataCollection intance
4. Create an instance of the PerformanceCounter class.
5. Make the PerformanceCounter instance writeable by setting the ReadOnly property to false
6. Assign CategoryName, CounterName. (Optionally we can set InstanceName and MachineName also).
7. Call, IncrementBy, Increment, Decrement or set RawValue (note, RawValue does not use Interlocked for multithreading)

These bullet points are reflected in the code below:

// 1. Create a new CounterCreationData instance 
CounterCreationData ccd = new CounterCreationData(
    "AAAACounter1", // Counter name
    "AAA Counter Help",  //Counter help text
    PerformanceCounterType.NumberOfItems32); //Counter type

// 2. Create a CounterCreationDataCollection
CounterCreationDataCollection ccds = new CounterCreationDataCollection();
ccds.Add(ccd);

// Code to demonstrate how to delete a category if we need to.
// PerformanceCounterCategory.Delete("AAAA");

// Check to see if our performance counter category if we need to
if (!PerformanceCounterCategory.Exists("AAAA"))
{
    // 3. Create the PerformanceCounterCategory
    PerformanceCounterCategory.Create(
        "AAAA",
        "AAAA Category Help",
        PerformanceCounterCategoryType.SingleInstance,
        ccds);
}

// 4. Create an instance of the PerformanceCounter class
PerformanceCounter PC = new PerformanceCounter();

// 5. Make the counter writable by setting the .ReadOnly property to false
PC.ReadOnly = false;

// 6. Assign the Category name and Counter Name.
PC.CategoryName = "AAAA";
PC.CounterName = "AAAACounter1";

// 7. Set the counter RawValue and increment
PC.RawValue = 0;
for (int x = 0; x < 100000000; x++)
{
    PC.Increment();
    if (x % 100 == 0)
    {
        Console.WriteLine(x);
    }
}

You may get a security exception when you execute the code. This is because the account under which you’re running the code does not have appropriate permissions on you operating system.

In which case, you’ll need to add the following to the application manifest:

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
  <security>
    <requestedPrivileges>
      <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
    </requestedPrivileges>
  </security>
</trustInfo>

This gets you around the problem, but may not be the best approach. For more info, consult: What do if you get a  SecurityException. I’d recommend reading it, as there’s more useful info on this with regard to alternative approaches.

Also note that this ensures the application requests privileges when it is run. This doesn’t help us help us when attempting to debug the application. For that, we need to run Visual Studio as an administrator. When I tried it with VS2012 on Windows 8, the application  prompted me about this, and then upon confirmation restarted automatically.

We can now view the new counter in Perfmon. Note, that all the counter and category information is loaded into Perfmon once when you start it up. To pick up any new or modified counters or counter categories, you’ll need to restart the application if  it’s already open.

Different Sorts of Pre-Defined Performance Counters

Out-of-the box

• Exception
• Interop
• JIT
• Loading
• Lock and Thread
• Memory
• Networking
• Security

Performance Counter Types

There are a large number of performance counter types. They are as follows (refer to MSDN for more information)

• NumberOfItems32/64, NumberOfItemsHEX32/64.
  
• RateOfCountsPerSecond32/64
• CountPerTimeInterval32/64
• RawFraction
• RawBase
• AverageTimer32
• AverageBase
• AverageCount64
• SampleFraction
• SampleCounter
• SampleBase
• CounterTimer
• CounterTimerInverse
• Timer100Ns
• Timer100NsInverse
• ElapsedTime
• CounterMultiTimer
• CounterMultiTimerInverse
• CounterMultiTimer100Ns
• CounterMultiTimer100NsInverse
• CounterMultiBase
• CounterDelta32/64

In general, we can break these counters down to five specific types:

1. Average: Measure a value over time and display the average of the last two measurements. Needs a base counter.
2. Difference: Subtract the last measurement from the previous one and display the difference
3. Instantaneous: Display the most recent measurement.:
4. Percentage: Display calculated values as a percentage.
5. Rate: Change in values ovwer time divided by the time period.

Some counters require a base counter. Base counters must be included immediately after the desired counter in the ConterCreationData structure.

There are four base counter types: AverageBase, CounterMultiBase, RawBase, SampleBase. Timers that require a base timer will start with the same text as those timers. For example: AverageTimer32 will require AverageBase.

Performance Counter Category Types

There are three types: Unknown, Single and Multi.

A counter is a single instance upon first creation. When other instances are created it becomes a multi-instance.

I thought I’d share an issue that I encountered recently with dynamic binding in C#, quite simply because I couldn’t easily find a solution out there on the net. In the end, it took the technical genius of a colleague of mine to identify the issue, and provide the solution.

The problem manifested itself when a test project was attempting to test a property on the Class Under Test of type object. At runtime this type was populated with an anonymous type by the Class Under Test.

At this point, it is probably more instructive to conjure a contrived example.

Consider a simple class library:

public class ClassUnderTest
{
    public object GetAnon()
    {
        return new { hint = 1 };
    }
}

Note that we return an anonymous type from the method, implicitly upcasting it to object. The anonymous type is declared within the method within the class, and so is treated by the compiler as internal to the class.

Now let’s consider a simple console application that attempts to access it.

private static void Main(string[] args)
{
    ClassUnderTest c = new ClassUnderTest();
    dynamic d = c.GetAnon();
    Console.WriteLine(d.member.hint);
}

The method GetAnon() of ClassUnderTest returns an object, thus denying us access to the members of the anonymous type. At this point we can access the properties via reflection, or if we’re being lazy (and naughty) set up an identical anonymous type and compare hash codes. (This is not to be encouraged: Principally because different types may generate the same hash, but there are other reasons which are outlined here on StackOverflow: http://stackoverflow.com/questions/16517392/is-it-safe-to-use-gethashcode-to-compare-identical-anonymous-types)

As it is, the solution above uses dynamic typing to achieve this effect. However, when you run it, the program throws a RuntimeBinder Exception:

‘object’ does not contain a definition for ‘member’

This is not a very helpful error message, and gives little clue as to the potential solution.

The problem is that because the anonymous type is internal to the declaring assembly, our client assembly cannot actually access this. To solve this, we have to make the assembly internal visible to the client application, which in this case is the unit test project.

We can emulate this in our sample solution by modifying AssemblyInfo.cs within ClassUnderTest  to contain the following:

[assembly: InternalsVisibleTo("ConsoleApplication1")]

In our real-world project we have to make internal of the Class Under Test visible to the test project.

Just recently, after deploying a web application to a testing environment, I was  approached by one of the testers complaining of an “Out of Memory” exception.

The application in question was a port of a legacy system (written in JSP and C++) from an unsupported Windows 2000 server to a more future-resistant .NET solution on a later, supported, version of Windows Server. Much of the original functionality was to be retained, and this was facilitated by the ability to copy/paste a large chunk of the original code (particularly the client-side JavaScript and static HTML).

However, some areas required developing from the ground up. One of these areas was the code that XML-formatted the data, and performed the XSLT transforms upon it. A particular headache was to get the whitespace recognition and treatment on the .NET platform to work the same as the older JSP system. After hours of trying different settings, in the end I was forced to reformat the underlying XSLT file just to get the screens looking the same. However, I digress…

With most of the major hurdles out-of-the-way, and the application delivered to testing, it was quite a disappointment to find a memory leak as the cause of the “Out of Memory” exception, especially at the scale I was noticing (50K+ per web page post).

I was pretty sure I had cleaned up unmanaged resources as required, but set about my code with a fine tooth comb to see if there was anything I missed. Eventually I fired up perfmon and stepped through the code line-by-line, looking for where significant memory consumption occurred.

I happened to notice significant memory consumption when stepping over the code that loaded the XSLT and performed the transformation (the equivalent to lines 5 and 10 in the sample below)

var xslCompiledDoc = new XslCompiledTransform(true);
//....
//....get myXSLDoc from some XSL file
//....
xslCompiledDoc.Load(myXSLDoc);
//....
//....get xmlSource and instantitate an XmlWriter
//....
//Memory leak on this line!!!
xslCompiledDoc.Transform(xmlSource, xmlWriter)

This restored my ego a little. It looked like the problem might be some side-effect of XslCompiledTransform, and not the result of overly crap code. It also meant that I had pinpointed where exactly the problem lay, even if I didn’t know how to solve it.

As it turned out, no one solution solved the problem, but it did lay bare an interesting problem with the System.Xml.Xsl.XslCompiledTransform .NET class. When executed, this class will take the XSLT that is passed to it, and compile it down to IL. The problem was that when the client application was run in debug mode, both the load and transformation leaked memory.

So here are the steps that I took to seal the leak:

1. XMLWriter Cleanup

Although the leak wasn’t all my fault, I may have been partially responsible. My first action was to correctly ensure that the XmlWriter unmanaged resource wrapper was cleaned up correctly:

using (XmlWriter xmlWriter = XmlWriter.Create(xmlStringBuilder, xmlWriterSettings))
{
    xslCompiledDoc.Transform(xmlSource, xmlWriter);
}

Using using in this context is considered all-round good practice for any class that wraps managed resources and implements IDisposable.

2. Debug Option Off

The first overload of the XslCompiledTransform constructor accepts a boolean parameter indicating whether or not to enable debug information, and therefore be able to debug the stylesheet itself.

You’ll note from my original code that I had this option set to true, which caused the load and transform to leak memory. The fix was to pass false explicitly, although I could have used the default parameterless constructor instead.

3. Caching in Session

The XslCompiledTransform class was designed to be initialised once (i.e. one call to the load function), and for that instance used for the duration of the application.When you think about it, there is little point in performing a compilation of XSLT to IL every occasion, unless the XSLT content itself is variable.

My code contained two static XSLT files, so I chose to cache these stylesheets in session once initialised. Technically, they could have been stored at application level once and their one instance re-utilised for every user. I must confess that this is not an option I considered at the time, but is something I can always revisit if needs be.

4. Release Mode DLL

The new version of the application was to be hosted within existing application infrastructure. Essentially, the port of the old application was to be a new web page within an existing website.

This existing website had been deployed in debug mode. Changing every module of a large website to release mode was not an option, so I moved all the supporting code out into a dedicated DLL that itself could be deployed in release mode on its own.

5. Precompiling XSL

After doing all this however, I was still observing a significant memory leak upon each page post (between 10K and 13K). The memory  leak was now reserved to the transform, but it was still occurring.

The last step, which eventually fixed the issue was to follow the advice set out at the end of this article:

http://blogs.msdn.com/b/xmlteam/archive/2011/09/26/effective-xml-part-5-something-went-really-wrong-outofmemoryexception-and-stackoverflowexception-thrown-when-using-xslcompiledtransform.aspx

Another way to resolve the problem is to compile the stylesheet “offline” (i.e. not at runtime) with the xsltc (xslt compiler, more details in MSDN http://msdn.microsoft.com/en-us/library/bb399405.aspx). This tool will create “regular” assemblies (.dll files) for the Xslt stylesheet and the embedded scripts. To be able to use them in your app you just need to add references. The memory leak problem is resolved – there is no compilation going on at runtime so no temporary assemblies are created.

At the time of writing this was required to be a manual build step. The actions that I tool specifically were to compile each of my XSLT files (input.xsl and output.xsl) into DLLs with equivalent names (InputXSL.dll and OutputXSL.dll) and internal class names (InputXSL and OutputXSL). This was done with the following syntax:

xsltc.exe /class:InputXSL /out:InputXSL.dll input.xsl

Note: the xsltc.exe executable took some finding. The one I needed was located in C:/Program Files/Microsoft SDKs/Windowsv7.0A/bin, however this will be dependent on the .NET framework version you are using. If you don’t have the framework SDK installed then you will need to do so.

Once the DLLs were compiled, I referenced them from the new component I created in step 4 above. This gave the code access to the internal class names just stipulated.

Finally, I updated the code itself to pass the respective stylesheet class to the XsltCompiledTransform load() function:

xslCompiledDoc.Load(typeof(InputXSL));

When this last step was completed, the memory profile of the application remained constant, and there were no observable memory leaks.

Previously I wrote about the The 10 Type Members of C#, and how it would be useful to list and understand each. In this article, I’ll take it a step further and refer to the identifiers and keywords of C# in the same context.

At the time of writing, According to MSDN, there are 77 Reserved Identifiers. These have a special meaning to the and cannot be used as a custom identifier unless they are prefixed with @. For completeness, they are:

Some of these have different meaning depending on the context, for example:

• using
• in
• out

MSDN also lists 23 Contextual Keywords. You can use these words as custom identifiers:

Again, some of these have an overloaded usage, for example:

• partial
• where

In contrast to my suggestion in the aforementioned article 10 Type Members of C#, I wouldn’t suggest that you be able to list them all off the top of your head. However, from a study perspective, I think this list is a good checkpoint of one’s understanding of the C# core. Understanding each one, even if you rarely or never use it, is useful thing.

Do you use a computer at work? If so read on.

When a company buys a clutch of machines for its employees, it’s quite often perceived as one of the largest single outlays it will have, and because of this, there will be a temptation to cut costs. What I hope to show in this article is the futility of doing this, and highlight the return on investment that buying top quality equipment will bring.

This idea started years ago at a previous employer, who made me write a justification the purchase for £30 worth of RAM. I spent an hour doing this. It probably cost the company more to pay me to write the justification than it did to buy the memory (which they did in the end).

So, let’s dive straight into some figures. Let’s take a look at a standard employee who:

Earns: £30000 a year

Works for 46 weeks (52 minus 6 weeks holiday), or 230 days a year.

Daily rate: £130 .

Let’s assume that a slow machine costs this employee just 1 minute of productivity per day.

Minutes Lost Per Year: 230.

Yearly Cost of Lost Minutes: £73.72 .

This sets the scene. I’m now going to make two more assumptions:

Machine Lifespan: 5 years

Daily Minutes Lost: 10 minutes

I base the first assumption on personal experience and observation. The second is a substantial understatement based on straw polls I’ve conducted around my colleagues.

So, based on our machine that wastes 10 minutes a day for 5 years for an employee earning £30,000:

£3700 Per Employee

Think of the kit you could get for £3700! Or even half that.

Let’s start scaling across all employees. An organisation with 100 employees, wasting 10 minutes per day per employee for 5 years racks up a cost of nearly £370,000.

And 100 employees isn’t even that big. I work for a company with roughly 2000 employees which given the above might translate to £7.4 million.

JUST BECAUSE OF SLOW MACHINES!

But that’s not all. We’re just measuring interrupted time. We’re assuming that a worker is at full-pelt either side of the interruption. In reality, there will be a time to “get back up to speed” after the interruption, which will vary by employee, role, and task.

There is a somewhat clichéd analogy that says that likens computers to cars, and staff to racing drivers. The argument goes along the lines of “If you want your driver [employee] to perform their best then give them the best car [machine].” Although one could pick substantial holes in this, the broad tenet of the idea holds true.

Enough? Well, no. An employee earning £30000 a year will actually cost more to the company. Consider:

• Employer National Insurance contributions
• Employer pension contributions (soon to be mandatory for every employer in the UK),
• Benefits,
• Office space costs,
• Utility bills,
• Network traffic,
• HR overhead.

In reality, the costs may be double the headline figures.

Aside from the costs of the individual employee, what about the costs associated with their role? Employees involved in a customer-facing role will want to be able to process customer requests quickly, to (1) aid customer satisfaction, and (2) get onto the next customer quickly. Substandard equipment can detract from the customer experience, as they take longer to be served and could spend more time in a call centre queue. A company investment in equipment could be a boast:  ”We equip our staff with the finest equipment, and this pays dividends.”

In addition to this, people are often excited about tech. That’s why we love our i[Device Name Here], or our 99″ 3D televisions, or our high-spec uber-powered games consoles. A decent bit of tech on their desk will often enthuse employees to come to work and use it.

Consider also, that workstations are part of the office environment, high quality of equipment contributes to a high quality environment. Why spend a quarter of a million of your favourite currency revamping an office space only to fill it with substandard equipment? A company spending money creating a productive environment must also consider this.

The largest cost for a company is hosting an employee in the building and paying their salary. Most company costs are directly related to employing staff and providing the environment for them to work. The cost of a high-powered machine is negligible – a pittance, and will provide the highest tangible and intangible return on investment that any company could possibly make.

So if this resonates, please share it. I firmly believe that each unit of currency invested in equipment (up to a sensible threshold) will yield triple-figure percentage returns. Do the math yourself, based on your organisation and show it to someone who pays the bills.

Continuing on from the last post where we define some custom attributes, let’s look at setting up a class AttributeUsers that will use these attributes.

Add a new class library to the main solution. This library will need to reference the custom attributes assembly.

Here’s the code:

namespace AttributeUsers
{
    [CustomClassLevel]
    public class AttributeUser
    {
        public void Setup() { /* setup actions */ }
        public void Teardown() { /* teardown actions */}

        [CustomMethodLevel]
        public void Message1()
        {
            Console.WriteLine("Message 1 Called");
        }

        [CustomMethodLevel]
        public void Message2()
        {
            Console.WriteLine("Message 2 Called");
        }
    }
}

Again, there’s nothing truly groundbreaking here, however let’s note a few points:

• The class is decorated with [CustomClassLevel]. 
• The class is decorated with [CustomMethodLevel].
• As it’s an attribute, the ‘Attribute’ is implied at the end of the name. We could have said [CustomClassLevelAttribute] instead and got an identical result.
• The methods emit a message to the console. Our goal will be to invoke these dynamically. They are parameterless for simplicity, however later we’ll look at passing data that is specified on the attribute.

You’ll also note the Setup and Teardown methods. Really, this is just a nod to the unit testing framework that we are trying to mimic, and serves no functional purpose. Later on, we’ll see that it’s not enough just to include a library in an assembly – we actually have to use something within it, otherwise the compiler omits it. When searching for assemblies that include attributes, we therefore must have used something in it in order for the Attribute Discovery algorithm to work.

Next up in part 5, we get the nuts and bolts of the attribute discovery, and how we leverage the reflection capabilities to do this.

So, in part 2 we looked at setting up a Visual Studio solution to host the project. We split it up into four parts:

• Attribute Discovery
• Custom Attributes
• Attribute User
• Host executable

In this part we’ll look at our Custom Attributes project. So, if you haven’t already created a solution project then do so now. Create a new Blank Solution under ‘Other Project Types -> Visual Studio Solutions’. When created, add a new C# Class Library to the solution. I’ve called mine JamesWisemanAttributes, but you can name yours in any way you want.

Let’s dive straight into the code:

namespace JamesWisemanAttributes
{
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
    public sealed class CustomClassLevelAttribute : Attribute
    {
        public CustomClassLevelAttribute() {}
    }

    [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
    public sealed class CustomMethodLevelAttribute : Attribute
    {
        public CustomMethodLevelAttribute() {}
    }
}

We should observe the following things about our code:

• They are simple classes derived from System.Attribute
• The constructor actually does nothing at the moment so could be omitted. (Later it will do something, which is why it’s included here)
• They are themselves decorated with attributes denoting their usage. The class attribute has a Class AttributeTarget and the method’s attribute denotes that it’s for a method only. We could combine these with an or ‘|’ operator.

And that’s really it. There’s nothing groundbreaking about this – we’re just setting up our projects and setting the scene.

Next up, we look at AttributeUser, the class that will use our attribute.

In this post we’ll start looking at the structure of the solution for the problem posed in Part 1.

Recall from the previous post that we were wanting to create a library that could iterate over an assembly looking for types with the attribute [MyClassAttribute] and then invoke methods within that class with the attribute [MyMethodAttribute].

Here’s an example of what this class might look like:

[MyClassAttribute]
public class MyTestClass
{
    [MyMethodAttribute]
    public void MyTestMethod()
    {
        Console.Writeline("MyTestMethod Called");
    }
}

Our end goal is to invoke MyTestMethod dynamically, and see the resulting “MyTestMethod Called” rendered to the console window.

So let’s start by looking at a solution that can support this. I’m using Visual Studio 2012:

Technically, we could host all of the code under one project, but I’ve chosen to split it up into the following^[1]:

• AttributeDiscovery contains the code that will walk our assembly/class/method walker.
• The rather narcissistically named JamesWisemanAttribute contains code that declares our custom attributes.
• AttributeUser is the class that will use the custom attribute, and as such should be picked up by the attribute discoverer.
• HostConsoleApp is the container app for all of this.

HostConsoleApp will reference all three other assemblies. AttributeUser will reference JamesWisemanAttribute. The other projects will reference nothing other than the Microsoft assemblies required for their execution (such as System.Reflection).

It is of particular importance that AttributeDiscovery references nothing. By doing this we are ensuring that it is loosely bound, and not dependent on any particular attribute or code library. That way we can point it at any assembly searching for any attribute.

Now we’ve defined the structure, in Part 3 we’ll start defining some code for our projects…

^[1] Yes, there’s no unit test project. Unit tests are important, and any production-grade code should have a suite of them. This is just a demo, and unit tests would not add to the discussion.