Boxing converts a value type to an object type. Or as MSDN puts it, boxing is an “operation to wrap the struct inside a reference type object on the managed heap.”
But if you try to drill into that by looking at the IL code, you only see the magic word “box.”
Speculating, I guess that the runtime has some sort of generics-based secret class up its sleeve, like Box<T> with a public T Value property, and boxing an int would look like:
int i = 5;
Box<int> box = new Box<int>;
box.Value = 5;
Unboxing the int would be far cheaper: return box.Value;
Unfortunately, my performance-hungry server application does a fair bit of boxing, specifically of decimals. Worse, these boxes are short-lived, which makes me suspect I pay twice, once for instanciating the box and then again for garbage collecting the box after I’m done with it.
If I was alloacting this memory myself, I would consider the use of an object pool here. But since the actual object creation is hidden behind a magic word in the IL, what are my options?
My specific questions:
- Is there an existing mechanism for inducing the runtime to take boxes from a pool rather than instanciating them?
- What is the type of the instance created during boxing? Is it possible to manually take control of the boxing process, yet still be compatible with unboxing?
If that last question seems strange, what I mean is that I could create my own Box<T> or DecimalBox class, pool it, and box/unbox manually. But I don’t want to have to go and modify the various places in the code that consume the boxed value (aka unbox it).
Your speculation is almost right. Logically you can think of a box as being a magical
Box<T>type that behaves as you describe (with a few more bits of magic; for instance, the way that nullable value types box is a bit unusual.) As an actual implementation detail, the runtime does not do it with generic types. Boxing existed in CLR v1, which was before generic types were added to the type system.If it hurts when you do that then stop doing that. Rather than trying to make boxing cheaper, stop doing it in the first place. Why are you boxing a decimal?
Short-lived is better than long lived; with short-lived heap objects you pay to collect them once and then they’re dead. With long-lived heap objects you pay that cost over and over again as the object continues to survive.
Of course, the cost you are probably worried about regarding short-lived objects is not the cost of collection per se. Rather, it is the collection pressure; more short-lived objects allocated equals more frequent garbage collections.
The allocation cost is pretty minimal. Move a pointer on the GC heap, copy the decimal into that location, done.
Right; you pay the cost of collecting the long-lived object more, but you do fewer collections total because less collection pressure is produced. That can be a win.
Nope.
The type of the box is the type of the thing being boxed. Just ask it by calling GetType; it’ll tell you. Boxes are magical; they are the type of the thing that they contain.
Like I said before, rather than trying to make boxing cheaper, just don’t do it in the first place.