NamedTypeBuildKey as a struct / boxing

Oct 17, 2008 at 7:34 PM
G'Day Chris,

What was the reason for using a struct for this?  Given most parts of OB2 reference the 'build key' as a reference type (object), rather than a value type, we are going to pay a boxing penalty (and thus allocating an object to box the struct), seemingly defeating the purpose of the stack-allocated object.

I've looked through most of OB2 and all the builder policies take an object for their build key, as does the builder context, so we'll actually box a single name-value key multiple times.

If I'm missing some other optimization or reason that the struct is beneficial, I'm very interested to learn.

BTW, I'm very much looking forward to the new features (Interception) in Unity 1.2 - great stuff!


Oct 18, 2008 at 3:47 AM
To be completely honest, I don't remember. It's definately something to keep in mind for future optimizations, though.
Oct 18, 2008 at 6:56 AM
No worries at all, mate.  I happen to be in a situation to be able to profile OB2 inside a large, enterprise application using dotTrace.  I have generated some interesting profile data and wanted to share with you, so you can incorporate whatever you desire into a future release.

We're using OB1 / CAB in a commercially shipping product in two different scenarios, that being a single-user WinForms product and a web application that needs to scale well.  Previously OB1 was a very significant bottleneck; however, we optimised significantly and want to benchmark OB2 to ensure it performs similarly (or better).  Anything I find, I'll be more than happy to share in these newsgroups if you consider that the best approach.


Oct 18, 2008 at 6:55 PM
I'd love to see your benchmark results on OB2. We've done some ourselves, of course, but more on the "micro-benchmark" level to test specific tweaks. Seeing overall perf behavior in a full scale app that we didn't write would be very valuable.