Saturday, November 3, 2012

Spot Contractor - A Software Pattern



Whenever an API-call is made frequently, but ideally it should be called conditionally. The conditional call construct adds performance, but since it is optional, it is not done in major parts of the code.

Context Example - Logging

A logging call can be made as follows:

For performance reasons the call should be

The log.Info call is more CPU and memory expensive than the log.InfoEnabled call.
We can expect that the first construct is cheapest, if info level is enabled, but the later construct is fastest and cheapest, if info level is disabled.  

Should you now feel biased towards the first construct, just think the example with logging level debug or trace. Furthermore, consider the following run-time measurements if you are not convinced about the above performance arguments:

If info level is disabled the 2nd construct is over twice as fast as the 1st construct and the GC collects generation 0 objects about 5 times as seldom with the 2nd construct as the 1st construct.
If info level is enabled they perform almost the same.


The design problem at hand is that the conditional API-call can be omitted. By design it is optional, so the simple construct will continue to be added to the code base; it is simple and works. A design change that will force programmers to make the ideal construct is desired. 


  • The expensive and slowest construct is easiest.
  • The performance gain of the conditional construct might not be obvious.
  • The usage of the API-call might be high and scattered around in the code base.
  • The API-call might be secondary to the problem being solved in the context; focus is not on performance.


The solution is to expect an evaluation API-call before the desired API-call can be made:
  • Create an evaluation API-method that stores a caller argument and returns true, if the matching API-method is expected to be called by the same caller, and
  • Create the matching API-method to take a caller argument that is checked against the stored caller argument.  
The evaluation API-method serves to establish a contract between the API and a specific caller. If the evaluation API-method returns false, no contract exists. Otherwise, the caller is contracted to call a matching API-method to get released from the contract.
If a caller tries to use the API without an evaluation API-call that returns true, the API can throw an exception.
If a caller does not free himself via a matching API-call, the API can throw an exception on next call and name the caller that did not fulfill a contract.

Solution Example - Logging

The conditional logging construct can be turned into a Spot Contractor as follows:

The API simply requires the addition caller argument:

Performance of this API compared with the prior 2 mentioned constructs can be discussed from the following test results:

If info level is enabled the 3 constructs perform similar, but if info level is disabled the Spot Contractor construct performs as good as the conditional construct. 

In summary the Spot Contractor pattern can be used to force logging usages into performance optimized constructs. 

As a side note it is since C# language v. 3.0 possible to turn InfoPrepare() and Info() into a single method using lambda expressions. The Common.Logging framework has extended its API to do so - you can read about it here.

Solution Example - Assert/FailFast

Another case where strings are allocated even though not used are in Assert or FailFast calls where error messages are passed as arguments. In these cases the Spot Contractor pattern can be used to improve performance.

Solution Example - Measurement Start/Stop

A common way of measuring performance is to use Start + Stop calls with a measurement name argument. In this case the Spot Contractor pattern can be used to force in a check whether performance measurement is enabled at all.

    Friday, November 19, 2010

    More Native Reflection, Please!

    Sometimes you wonder why you keep on producing the same kind bugs again and again...
    ... and you hope someone will show you how to find a remedy.

    This post is left to be found by the programming language designers of today... and whoever finds it interesting.

    The Problem - Example #1

    PropertyInfo propertyInfo = this.GetType().GetProperty("SomePropertyName");

    Above very powerful state of the art reflection fetches a PropertyInfo instance that can be used to set/get property "SomePropertyName". The Type class facilitates a number of reflection services as normal C# members in a very general and loose coupled manner e.g. you enter a string in the GetProperty-method.
    The problem comes when someone renames SomePropertyName with a built-in refactoring utility of an IDE. The string argument is a weakness in above code that just waits to break the code.

    The Problem - Example #2

    [Reference(InitializeFromPropertyId = "EntityId")]
    SomeEntity ReferenceEntity

    Imagine that above code is part of an interface or class and it means that the class - when instantiated - will initialize a reference to another entity of type SomeEntity using property EntityId. This time we have the same problem - the string argument in the annotated Reference-attribute won't be changed if the property name is refactored.

    Counter Example

    Type type = typeof(Org.Foo.Bar.MyClass);

    Above works like a charm with refactoring. If MyClass is renamed, the code doesn't break.

    The Simple Solution

    PropertyInfo propertyInfo = propertyof(Org.Foo.Bar.MyClass.SomePropertyName);

    Could you guys* (continue to) make reflection part of the programming language! ... Please ... Soon?

    * Anders Hejlsberg and others...

    Sunday, October 17, 2010

    Code generation with partial & Attribute

    The last couple of weeks I have built a Visual Studio Addin that can help up with trivial editor features and not so trivial features like code generation.

    One of the things that I am going to try the next couple of weeks is to generate a default implementation class from an interface.

    2 ways to structure basic code generation in C# are:
    • the C# form approach where a class is split into 2 files (1 generated and 1 editable) with the partial keyword, and
    • the "double-derived" pattern with a base and implementation file (1 generated and 1 editable)
    The first mentioned approach doesn't support that you can choose what should be generated and what shouldn't; you just have to live with the split made by the generator.
    The second approach adds an extra inheritance link and you avoid calling the generated code by overriding methods/properties and not calling it via base; generated code becomes dead code.

    Here is a 3rd approach... and I have yet to see if it works in practice.

    Generate a partial class with 2 files
    First we generate "Class1.cs", the editable file, and "Class1.generated.cs", the generated file.

    They could look as follows:
    Now the developer wants to customize the Bar property...

    Support developer customization
    The developer cut-paste the Bar code to the editable file, removes the Generated attribute and performs her customizations:
    What happens now when the code generator is called again to create Class1?

    Re-generate the partial class generated file
    The generator uses reflection on the compiled assembly and only generates missing properties/methods and re-generates the properties/methods with the Generated attribute....

    This means that the developer's changes are kept intact and she actively decides on the features being generated.

    Maybe it can be done that simple... the catch is that the generator only can respect successfully compiled developer changes... but that might be OK e.g. Test Driven .Net requires a successful build to run tests.

    Sunday, August 15, 2010

    Version-ed interfaces to refine a product specification?

    Warning! This is just an idea. You will have to prove its value yourself!

    Interfaces as product specifications
    Nothing new here.
    An interface defines some behavior that can be implemented by one or more classes.

    Interface methods and properties
    • define inputs and outputs (interfaces as arguments and return types),
    • may have annotations (attributes that means something), and
    • have documentation (e.g. with references to specifications and/or examples).
    Version-ed interfaces
    Here comes the first idea.
    Lets say that a product release of some features are to be version 1.
    Here is what a (wacky) coder could have produced to materialize one of those features:

    The 1st idea is to name the interface with a version number.

    "Thats just insane! Why would you do that! ....."

    Usually we don't change the name of the interfaces and it works fine, but lets see the next Foo specification:

    This certainly is a bit strange. Apparently, now a Foo does not drink stuff from the bar, but only buys it. Definitely, strange.

    This version 2 interface is renamed, specializes the previous interface by inheriting it and redefines the Bar method by using the new keyword.

    Thats 3 things that you normally do not see:
    • The rename: It will have no effect on existing version 1 implementation, but require your implementation to be changed when it is to support version 2.
    • The specification inheritance: This is a very explicit way of tracking the specification history that might suite coders just fine.
    • The redefine with new: The Bar signature did not change, but the textual specification did. If the interface was named IFoo and the text just changed between version 1 and 2, then the compiler would eat everything just fine, but the version 1 implementation would still make Foo drunk whenever he went to the bar.
    Implementation changes
    Here is how a version 1 implementation could look:

    The version 2 could be:

    A tiny difference, but a fatal one when on a date!

    Saturday, July 25, 2009

    How to host Silverlight (.xap) on Google App Engine with Java SDK

    ...or any other file with a MIME-type that Google App Engine does not treat nice by default.

    Problem: Lack of control over MIME-types and static files on Google App Engine

    Apparently, it is not possible to host a .xap file as a static file on Google App and register a correct MIME-type for it. If you search around, you might find hints that it is possible to do with the Python SDK (configuring handlers), but you might also find people can't get the MIME-settings to work with the Java SDK. Recently, I was one of the later, so here is a solution for you that hopefully will save you some time.

    Solution: Create a servlet that loads the .xap file as a resource and streams it to the client
    This part might sound complex but really is simple. Here are the steps to get it working, though you might need to refine it for production:

    1) Produce your .xap file, test .html file and silverlight.js file and copy those into your war folder. Here is my test example structure in an Eclipse project:

    2) Create a HttpServlet-extending Java class file (that I named with content similar to the following:

    3) Register .xap files as a servlet resource in appengine-web.xml:

    4) Register your servlet and URL-patterns in file web.xml:

    5) Deploy your app as you normally do, visit the test .html page and enjoy your Silverlight app.

    Here is a running example: (click and move your mouse).