eSpace Blog RSS
12Nov

Ruby Fibers Vs Ruby Threads

1

Ruby 1.9 fibers are touted as lightweight concurrency elements that are much lighter than threads. I have noticed a sizable impact when I was benchmarking an application that made heavy use of fibers. So I wondered, what if I switched to threads instead? After some time fighting with threads, I decided I needed to write something specific for this comparison. I have written a small application that spawns a number of fibers (or threads) and then returns the time that went into this operation. I also recorded the VM size after the operation (all created fibers and threads are still reachable, hence, no garbage collection). I did not measure the cost of context switching for both approaches; maybe I'll do that another time.

Here are the results for creation time:

And the results for memory usage:

Conclusion:

Fibers are much faster to create than threads; they eat much less memory too. There is also a limit on the number of threads for 1.9, as I maxed on 3070 threads, while fibers were not complaining when I created 100,000 of them (but they took 203 seconds and occupied a whooping 500MB of RAM).

Written By:

Muhammad A. Ali (oldmoe.blogspot.com)

Comments

1 Fizo wrote: on Saturday, November 22, 2008:

Context Switching?!
I am not sure how do u plan to compare between threads and Fibers from the context switching point of view.
the main purpose of the fibers is to be user level threads, so u can switch between different fibers regardless to the OS dispatching policy and another important point is that OSS put a limit on the number of threads (that wt u already prooved in Ruby)
in Some OSs threads are converted into Fibers just before executions.

Post a Comment

eSpace podcast Prodcast

RSS iTunes

Archive

Latest Comments