Re: fast mutexes for 1.8?

On Tue, 7 Nov 2006, Hugh Sasse wrote:

> On Tue, 7 Nov 2006, Eric Hodel wrote:
> 
> > As has been discussed further down in this thread, there isn't much to do to
> > make Mutex faster.  The only remaining thing is to avoid Mutex#synchronize
> > when you need to be really fast.  The block invocation overhead huge.  Instead
> 
> It is really only a lock; begin; yield; ensure; unlock; end;
> Blocks are pretty central to Ruby.  My reading of eval.c suggests
> that it might be possible to optimise
> rb_yield_0(val,self,klass,flags,value) for the cases where self,
> klass and flags are known to be 0, as they are when rb_yield is
> called.  This would result in some code duplication, however.  Has
> anyone explored this?  I'm just thinking that given the amount of
> grief Ruby gets for its perceived low speed, that it might be worth
> examining.  I'm not aware that compilers can optimize this sort of
> thing away.

To follow up on my own suggestion, I have attempted this optimization
and have managed to remove 7 lines from a 226 line method body.
Most of those were (...flags...)?...:...; statements.
I conclude that the gains are not worth the code duplication that results,
and refactoring common code out to another function would be bound to 
make things slower than tney are (function call overhead).
> 
> > use #lock, #unlock and ensure.
> > 
>         Hugh