Performance improvement of ActionBlock on the posting side

Issue: https://github.com/dotnet/corefx/issues/243

One of the main scenario where ActionBlock is expected to be used is direct posting to it via Post method. The instance method was added only for performance reasons.
 But there is still opportunity to improve its perf by up to 60%.
 Changes are fairly small and simple.
 
Here is microbenchmarking results for the current and updated ActionBlock for x64 build on ultrabook level Intel i7 processor:

============= Current ActionBlock results ==================
 ActionBlock[int]. Million times a sec:
 48,882
 48,781
 47,528
 46,906
 30,912

ActionBlock[object]. Million times a sec:
 39,113
 38,321
 37,792
 37,439
 19,728

ActionBlock[WideStruct]. Million times a sec:
 12,944
 10,377
 10,066
 8,754
 8,46

============= Updated ActionBlock results ==================

ActionBlock[int]. Million times a sec:
 80,048
 74,754
 70,859
 67,143
 30,164

ActionBlock[object]. Million times a sec:
 57,761
 56,573
 54,980
 33,335
 32,809

ActionBlock[WideStruct]. Million times a sec:
 18,357
 16,191
 10,233
 9,483
 8,209

x64 JIT doesn't inline it. Nor does x86 one. 
But I still think the attributes on both methods should be present.
It is unlikely that after so many years JIT compiler will generate significantly different or better  code. But its inlining heuristics  may and do change accommodating it to a broader range of scenarios. And still it is a JIT compiler - it can't spend too much time on analysys. Our brains can.
We can spend hours optimizing code of a few dozen lines. When we know  (for example :)) that this call site must be as dense as possible and that method on the slow path should not increase  it  and grab half of available registers then   we do we don't  the  next version of  JIT accidentally get into the way. I think for such highly optimized and perf sensitive library as TPL Dataflow  the rules must be different.
Besides that the attributes document our concern for future devs.

Having said that, I will rely on your opinion. You've been taking part in developing and supporting libraries that  many years  are used by millions devs.