C# - Is it possible to pool boxes?

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 l开发者_Go百科ook 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).

---

Speculating, I guess that the runtime has some sort of generics-based secret class up its sleeve

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.

my performance-hungry server application does a fair bit of boxing, specifically of decimals.

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?

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.

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.

If I was alloacting this memory myself, I would consider the use of an object pool here.

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.

Is there an existing mechanism for inducing the runtime to take boxes from a pool rather than instanciating them?

Nope.

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?

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.

---

The runtime does pretty much what you describe, however generics is not involved, as generics was not part of the original framework.

There isn't much that you can do about boxing, if you are using some code that expects boxed values. You could create an object that uses the same syntax to return a value by overriding implicit conversion, but that would still need to be an object, and you would basically do the same amount of work anyway.

Trying to pool boxed values will most likely degrade the performance rather than increasing it. The garbage collector is specially made to handle short lived objects efficiently, and if you put the objects in a pool they will be long lived objects instead. When objects survive a garbage collection, they will be moved to the next heap, which involves copying the object from one place in memory to another. So, by pooling the object you may actually cause a lot more work for the garbage collector instead of less.

---

There is no class like Box<T> by default. The type is still the original type, but is a reference. Since Decimal immutable you can't change the value after creation. So you can't really use pooling with normal boxed decimals.

You can avoid boxing for values that reoccur by implementing a cache. Or you need to implement your own box type.

Your own box type can't be unboxed from object with a standard cast though. So you will need to adapt the consuming code.

---

Writing your own method that returns a boxed value:

[ThreadStatic]
private static Dictionary<T,object> cache;

public object BoxIt<T>(T value)
  where T:struct
{
  if(cache==null)
    cache=new Dictionary<T,object>();
  object result;
  if(!cache.TryGetValue(T,result))
  {
    result=(object)T;
    cache[value]=result;
  }
  return result;
}

One problem with this simple implementation is that the cache never removes items. I.e. it is a memory leak.

---

int i = 5;
object boxedInt = i;

Assigning a value type to a System.Object is more or less all there is to boxing as far as your code is concerned (I won't get into boxing operation technical details).

Keeping your decimal values in System.Object variables can shave off a bit of time from boxing, and creating System.Object instances, but you always have to unbox. This gets harder to impossible if you have to change those values frequently since every change is an assignment, and therefore a boxing at least.

There is an example of this practice though - the .Net framework uses pre-boxed boolean values internally in a class similar to this:

class BoolBox
{
    // boxing here
    private static object _true = true;
    // boxing here
    private static object _false = false;

    public static object True { get { return _true; } }
    public static object False { get { return _false; } }
}

The WPF system often uses System.Object variables for dependency properties, just to name a case where boxing/unboxing is unavoidable even in these 'modern times'.

---

Unfortunately you can't hook the boxing process, however, you can use implicit conversions to your advantage to make it 'look' like boxing.

I would also steer clear of storing each value in a Dictionary - your memory problem will get worse. Here is a boxing framework that could be useful.

public class Box
{
    internal Box()
    { }

    public static Box<T> ItUp<T>(T value)
        where T : struct
    {
        return value;
    }

    public static T ItOut<T>(object value)
        where T : struct
    {
        var tbox = value as Box<T>;
        if (!object.ReferenceEquals(tbox, null))
            return tbox.Value;
        else
            return (T)value;
    }
}

public sealed class Box<T> : Box
    where T : struct
{
    public static IEqualityComparer<T> EqualityComparer { get; set; }
    private static readonly ConcurrentStack<Box<T>> _cache = new ConcurrentStack<Box<T>>();
    public T Value
    {
        get;
        private set;
    }

    static Box()
    {
        EqualityComparer = EqualityComparer<T>.Default;
    }

    private Box()
    {

    }

    ~Box()
    {
        if (_cache.Count < 4096) // Note this will be approximate.
        {
            GC.ReRegisterForFinalize(this);
            _cache.Push(this);
        }
    }

    public static implicit operator Box<T>(T value)
    {
        Box<T> box;
        if (!_cache.TryPop(out box))
            box = new Box<T>();
        box.Value = value;
        return box;
    }

    public static implicit operator T(Box<T> value)
    {
        return ((Box<T>)value).Value;
    }

    public override bool Equals(object obj)
    {
        var box = obj as Box<T>;
        if (!object.ReferenceEquals(box, null))
            return EqualityComparer.Equals(box.Value, Value);
        else if (obj is T)
            return EqualityComparer.Equals((T)obj, Value);
        else
            return false;
    }

    public override int GetHashCode()
    {
        return Value.GetHashCode();
    }

    public override string ToString()
    {
        return Value.ToString();
    }
}

// Sample usage:
var boxed = Box.ItUp(100);
LegacyCode(boxingIsFun);
void LegacyCode(object boxingIsFun)
{
  var value = Box.ItOut<int>(boxingIsFun);
}

In all honesty you should make another question - and ask for advice on how to get rid of this boxing issue you have.

---

I just blogged about our box cache implementation that we use in our object database engine. Decimals have such a wide range of values that caching boxes wouldn't be very effective, but if you find yourself necessarily using object fields or object[] arrays to store a lot of common values, this might help:

http://www.singulink.com/CodeIndex/post/value-type-box-cache

Our memory usage dropped like crazy after using this. Essentially everything in the database is stored in object[] arrays and can be many GB of data so this was hugely beneficial.

There are three main methods you will want to use:

• object BoxCache<T>.GetBox(T value) - Gets a box for the value if one is cached otherwise it boxes it for you.
• object BoxCache<T>.GetOrAddBox(T value) - Gets a box for the value if one is cached otherwise it adds one into the cache and returns it.
• void AddValues<T>(IEnumerable<T> values) - Adds boxes for the specified values into the cache.