From: Brad Volz <bradv@...>
Date: 2008-09-14T16:48:04+09:00
Subject: Re: how can i find lingering file descriptors?


On Sep 13, 2008, at 10:40 PM, ara.t.howard wrote:

>
> On Sep 13, 2008, at 6:25 PM, Brad Volz wrote:
>
>> I just tested 0.0.4, and it seems to work just as well as threadify  
>> at keeping the file descriptors under control.
>
>
> great!
>
> guess i left some pipes lying around in the initial version ;-(
>
> say - which of the two, threadify and forkoff, was fastest for your  
> use case?

It looks like threadify is.

The following test attempts to be "fair" by specifying 4 threads for  
threadify, and 4 processes for forkoff since their defaults are  
different.

bradv:bvolz:$ !!
ruby netflow.rb
2391 items in Enumerable
starting threadify execution
{:flows=>150148, :packets=>76875776, :octets=>68717894144}
threadify execution time: 108.343915224075
starting forkoff execution
{:flows=>150148, :packets=>76875776, :octets=>68717894144}
forkoff execution time: 143.863088130951
bradv:bvolz:$

In my case, I'm not doing the calculations in ruby code.  I'm calling  
an external program to fetch the data for me, so in both cases there  
is an external process that can be scheduled by the operating system  
onto whatever processor has cycles.  Presumably, if that were not the  
case, and I was doing a lot of cpu intensive work in Ruby itself, the  
forkoff version would be faster by providing 'n' GIL instances instead  
of just one.

cheers!

Brad