Reply to thread

Message: [QUOTE="Brad Volz, post: 4618784"] 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 [/QUOTE]