Forum: Ruby Re: FasterGenerator (#66)

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
1c1e3bdfe006a22214102fcd6434a012?d=identicon&s=25 Daniel Sheppard (Guest)
on 2006-02-14 07:59
(Received via mailing list)
> :)
>
> James Edward Gray 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.
This topic is locked and can not be replied to.