# Re: FasterGenerator (#66)

**URL:** <https://www.ruby-forum.com/t/re-fastergenerator-66/53753>\
**Category:** Ruby\
**Created:** [February 14, 2006, 7:59am UTC](https://www.ruby-forum.com/t/re-fastergenerator-66/53753 "2006-02-14T07:59:25Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![dasch](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/b2d939/32.png) [@dasch](https://www.ruby-forum.com/u/dasch)\
**Post date:** [February 14, 2006, 7:59am UTC](https://www.ruby-forum.com/t/re-fastergenerator-66/53753/1 "2006-02-14T07:59:25Z")

</div>

> 🙂
> 
> James Edward G. II

Which makes perfect sense, since Mutex is simply wrapping around  
Thread.critical, Thread.stop and Thread.wakeup.

Mutex, as simple as it is, is overkill for what you’re trying to do here  
(switch between two threads in a deterministic manner). Since the number  
of threads is fixed, you don’t need to keep the thread list in an array,  
and you can drop a couple of other checks because you know all the  
calling code.

If raw speed is your goal, relying on any pure ruby will never get you  
faster than just inlining the subset of that code that you’re interested  
in using - even if you’re just completely duplicating the logic, it’s  
going to be that slightest bit faster as you’ve reduced the number of  
messages sent - and I think it’s safe to say that reducing the total  
number of message sends will always make your program faster, barring  
any change in IO.

That’s not to say that inlining bastardised versions of other libraries  
is a good idea… except where it is.

Now, if somebody went and implemented the thread standard library as a C  
extension, then it might be worth using in this context… or maybe not.