Control Freaks

December 28, 2007 § Leave a comment

Whew, what a fun day this has been! I got side-tracked from doing some useful work and spent time refactoring a bit of the Engine and generally tidying things up for the first few hours this morning. The result is that everything now has XML documentation, and I’m more happy with the structure of the engine (only minor moves). I started work on controllers as well. Now, controllers are not currently needed in the engine… but they will be! So please don’t attack with that huge YAGNI stick, because we are, honest!

Being me, I wanted to make the most efficient implemantion possible, while also sticking to being as clear and reusable as possible. However, it’s hard to just say “this is efficient” and “this isn’t efficient” without some hard facts, as all good programmers know, so I sat down and wrote some profiling utilities. Moebius, the engine for Overload (which I may open source, who knows), now has a lovely profiling API for what I’ve needed so far.

A discussion over at GDNet started by myself about ways to implement this controller system gave a few ideas. So, I typed out some code of how I’d like the system to look, and then added the profiling API on top. Here’s the code:


TestSubject subject = new TestSubject();
Profiler profiler = new Profiler();

LambdaIncrementerController lambdaController = new LambdaIncrementerController(delegate(float newValue) { subject.Value = newValue; }, delegate { return subject.Value; });
ProfileResults lambdaResults = profiler.Profile(delegate { lambdaController.Update(1); }, 1, 10000, 500, 5);

subject.Value = 0;
InterfaceController interfaceController = new InterfaceController(subject);
ProfileResults interfaceResults = profiler.Profile(delegate { interfaceController.Update(1); }, 1, 10000, 500, 5);

subject.Value = 0;
AttributeController attributeController = new AttributeController(subject, "Value");
ProfileResults attributeResults = profiler.Profile(delegate { attributeController.Update(1); }, 1, 10000, 500, 5);

The final system there utilizes reflection. By searching the “subject” for a property which has the ControllableAttribute, and it’s ExposedName set to “Value.” I have had prior experience with Reflection in .NET and I’ve never found it particularly speedy. This was reflected (ha! sorry…) in my profile results; the AttributeController was about 100 times slower than the other 2 – y’ouch!

I did get slightly more sidetracked though today… This sure is a case of YAGNI! I decided that it would be nice to include some graphics in this blog post, and thought a graph visualizing the profile results would be good. I don’t have Excel though, nor the space to install it on this 5GB Windows partition, so I thought if I could get some SVG graph output, then I could just chuck it into Inkscape. The only thing I could find was a Ruby module, and I couldn’t be bothered to install Ruby just for that, so I wrote my own SVG grapher (yea, cause that was faster than just downloading Ruby…)

So, here’s the results of profiling the two potential candidates:

 controllersystem.png

Pretty neat I think! But I’m still torn between which system I want to take. Both are as efficient as it’s going to get (without exposing public fields instead of properties, but I’m not doing that) – and have there advantages and disadvantages. I think when I get round to writing specific controllers I’ll just decide if it makes sense for a controller to control any arbitrary value, or if it is very reusable. KeyFrameController, would be a perfect time to use my lambda/anonymous methods, but FadeOutController would be a good time to use the interface controller pattern (with IFadeable).

Where Am I?

You are currently browsing entries tagged with profiling at Cycles.

Follow

Get every new post delivered to your Inbox.