One-bytes #1: Menu item commands, boxing vs. ToString()

Hello there!
With this post I’m starting new category: one-bytes. These posts will be compiled of two or three shorter forms abut things that don’t qualify for so to say full-size post. Name of the category refers to snack meals, so called one-bite foods: one bite => one byte. Quick to prepare, good to get your taste-buds tingling.  Enjoy!

*** #1.1 Binding a command to MenuItem in ContextMenu ***
It happend one time that I had been struggling with binding a command to a MenuItem in ContextMenu. The code was more or less like this:

It turned out that since ContextMenu is not present in WPF visual tree it was not possible to bind the command as it’s usually done. The solution was to use BindingProxy class that inherits from Freezable.

Having this class we can create its instance as a resource (in my case it was an user control) and set the Data property to {Binding}:

This will bound the Data property to whatever is set as DataContext in the user control itself. Now, through the BindingProxy instance we can access that DataContext outside the visual tree:

This solution was proposed by Thomas Levesque.
Sources:
Blog post by Thomas Levesque
Question on StackOverflow

*** #1.2 String.Format() vs. boxing ***
There is a thing using String.Format() method with value types (such as integers). That thing is the fact that this method takes objects as args and if a value type given as parameter it will be boxed. Boxing is a process when a value type is converted to an object. That involves moving the value from stack to heap and replacing it on a stack with a reference to heap address where the actual value is stored. (More on boxing/unboxing can be found here: [link]).
So, what can be done to avoid that – simply pass arguments with ToString() method invoked. This will save a bit on performance – that’s the theory. So I tested it. I take an array of one million integers and another array with the same amount of doubles and pass them into String.Format() method. And the theory is confirmed – avoiding boxing by invoking ToString() method makes it faster.

To make the results reliable I arranged everything as unit tests run one after another (not parallel) and the actual tests were preceded by a test that did nothing – that is to make sure that the filling arrays in test class constructor does not distort actual test running time. So the results are that the process without boxing is faster by 3,7% for doubles and 4,9% for integers. Please, keep in mind that the test sample was one million values.
Does it mean that it’s no point in invoking ToString()? My opinion is that in this case boxing operation is redundant and not necessary so it should be avoided.