Given that I have pointed people in the Develop Conference presentation to our website, I figured it might be a good idea to upload some preliminary documentation to give a bit more insight how the generic data API layer in the talk might look. You can find the documentation for the central classes of the data API here.

The docs are still work-in-progress (though the libraries themselves are already in use), but to give some more technical background information to the presentation for the Develop Conference, I think it might be useful to have this pre-release of the documentation.

If you have seen the presentation on the Develop Conference (you can download the presentation here), you might want to first read the chapter about the Architectural Overview and then have a closer look at the Spielwerke.Data namespace providing the generic data API. Any remarks and questions regarding the documentation, feel free to leave some comments.

We will release a complete evaluation version with a little editor demo to play around with and complete documentation. If you are interested in that, drop us a note at This e-mail address is being protected from spam bots, you need JavaScript enabled to view it (and don't worry, we won't hassle you with lots of mails).

Welcome to this attempt to have an outlet for thoughts, programming quirks and other oddities which might be of general interest.

In course of the work for Spielwerke, I had to investigate .NET performance for access to properties via reflection. The .NET framework offers two ways for this: direct reflection (System.Reflection) and "reflection" via System.ComponentModel.TypeDescriptor - surprisingly, the latter can turn out to be faster than the former, especially if your types implement System.ComponentModel.ICustomTypeDescriptor.

If you have looked into .NET performance pitfalls before, it might not surprise you how slow the normal reflection is: a simple test with repeated access to an int property proved to be ~1000 times slower using reflection compared to the direct access to the property (comparing the average of the median 80% of the measured times).

Fortunately there are some ways to do the dynamic access a lot faster: starting from the examples in this article from James Nies - which also has some measurements regarding performance - and this one from Tobias Hertkorn, it is possible to get a property accessor together which uses for creation and access only the object reference and the name of the property in the object, and uses only .NET 2.0 standard C# (no emitting of MSIL code) and runs less than 10 times slower than the direct access - still a magnitude difference, but at least two magnitudes faster than using reflection as it normally works. I hope I will find the time to elaborate on that soon. 

Lesson learned: try to avoid dynamic calls - everything which uses Invoke with generic object parameters will be very slow.

Second lesson (re-)learned: reflectors can be a very, very useful tool to find out what .NET does internally.

Achim