CODEWITHSUNDEEP
rubymultithreadingconcurrency
user2398029
user2398029

Reputation: 6937

Can concurrency improve performance?

I understand that in Ruby running on YARV, threads mean concurrency rather than parallelism. My question is: what are the situations in which concurrency alone can improve performance? For example, I can imagine that concurrency would improve performance when dealing with several IO streams at the same time - if one task is slow, that doesn't mean all the next tasks in the stack have to wait for that task to finish. Am I right? Are there any other cases like this? Is the [hopes that YARV will ever remove the GIL]/[overhead of creating threads with the GIL] ratio worth starting to use threads in Ruby at the present moment?

Upvotes: 3

Views: 1053

Answers (2)

Lindydancer
Lindydancer

Reputation: 26114

One situation where the Ruby model works well is when you use Ruby to drive other applications. For example, if you spawn off, say, compilations, you could have one Ruby thread handing one external process.

Another good thing is that it allows you to divide your application into logical parts, and let one thread handle each part. Doing that using only one thread would probably require you to write a far more complex application.

Upvotes: 0

templatetypedef
templatetypedef

Reputation: 372814

Concurrency can be enormously beneficial in situations where you have multiple tasks that all need to wait for some external stimulus that does not occur frequently (for example, network data becoming available, disk reads finishing, etc.) If you just sat in a loop waiting for one of these operations to happen, you would either

  1. Wait for a long time for some single event to finish while others have already finished and are waiting for you to look at them, or
  2. Waste CPU power looping over hundreds of different events that haven't fired looking for events that actually have fired.

Concurrency is also useful in designing programs that are inherently event-driven, such as waiting for different UI events to occur. In this case, you can designate tasks that should fire in response to different UI events, and the processor can just sit dormant or working on other tasks without needing to explicitly wait for the tasks that haven't triggered to run. As soon as an event occurs, those threads can wake up and share the CPU processing time.

Hope this helps!

Upvotes: 8

Related Questions