title: Using ThreadStatic to replace expensive locals -- good idea?
body: <p><strong>Update</strong>: as I should have expected, the community's sound advice in response to this question was to "measure it and see." <a href="https://stackoverflow.com/questions/4864974/using-threadstatic-to-replace-expensive-locals-good-idea/4865914#4865914">chibacity posted an answer</a> with some really nice tests that did this for me; meanwhile, I wrote a test of my own; and the performance difference I saw was actually so huge that <a href="http://philosopherdeveloper.com/posts/replacing-expensive-locals-with-threadstatic-fields.html" rel="nofollow noreferrer">I felt compelled to write a blog post about it.</a></p>
  
  <p>However, I should also acknowledge <a href="https://stackoverflow.com/questions/4864974/using-threadstatic-to-replace-expensive-locals-good-idea/4865784#4865784">Hans's explanation</a> that the <code>ThreadStatic</code> attribute is indeed not free and in fact relies on a CLR helper method to work its magic. This makes it far from obvious whether it would be an appropriate optimization to apply in any arbitrary case.</p>
  
  <p>The good news for me is that, in <em>my</em> case, it seems to have made a big improvement.</p>
  
  <hr>
  
  <p>I have a method which (among many other things) instantiates some medium-size arrays (~50 elements) for a few local variables.</p>
  
  <p>After some profiling I've identified this method as something of a performance bottleneck. It isn't that the method takes an extremely long time to call; rather, it is simply called <em>many</em> times, very quickly (hundreds of thousands to millions of times in a session, which will be several hours). So even relatively small improvements to its performance should be worthwhile.</p>
  
  <p>It occurred to me that maybe instead of allocating a new array on each call, I could use fields marked <code>[ThreadStatic]</code>; whenever the method is called, it will check if the field is initialized on the current thread, and if not, initialize it. From that point on all calls on the same thread will have an array all ready to go at that point.</p>
  
  <p>(The method initializes every element in the array itself, so having "stale" elements in the array should not be an issue.)</p>
  
  <p>My question is simply this: does this seem like a good idea? Are there pitfalls to using the <code>ThreadStatic</code> attribute in this way (i.e., as a performance optimization to mitigate the cost of instantiating new objects for local variables) that I should know about? Is the performance of a <code>ThreadStatic</code> field itself perhaps not great; e.g., is there a lot of extra "stuff" happening in the background, with its own set of costs, to make this feature possible?</p>
  
  <p>It's also quite plausible to me that I'm wrong to even try to optimize something as cheap (?) as a 50-element array—and if that's so, definitely let me know—but the <em>general</em> question still holds.</p>