Ruby » Ruby master

Feature #20855

Updated by ioquatix (Samuel Williams) 24 days ago

The current Fiber Scheduler performance can be significantly impacted by blocking operations that cannot be deferred to the event loop, particularly in high-concurrency environments where Fibers rely on non-blocking operations for efficient task execution. 

 ## Problem Description 

 Fibers in Ruby are designed to improve performance and responsiveness by allowing concurrent tasks to proceed without blocking one another. However, certain operations inherently block the fiber scheduler, Fiber Scheduler, leading to delayed execution across other fibers. Fibers. When blocking operations are inevitable, such as system or CPU bound operations without event-loop support, they create bottlenecks that degrade the scheduler's overall Scheduler's performance. 

 ## Proposed Solution 

 The proposed solution in PR https://github.com/ruby/ruby/pull/11963 introduces a `blocking_region` blocking_region hook in the fiber scheduler Fiber Scheduler to improve handling of blocking operations. This addition allows code that releases the GVL (Global VM Lock) code to be lifted out of the event loop, reducing the performance impact on the scheduler Scheduler during blocking calls. By isolating these operations from the primary event loop, this enhancement aims to improve worst case performance Fiber-based concurrency, especially in cases where non-deferrable blocking operations would otherwise delay the presence of blocking operations. Fiber Scheduler. 

 The new fiber scheduler Fiber Scheduler hook `blocking_region` blocking_region is designed to accept an opaque callable object, which encapsulates work that can be offloaded to a thread pool for execution. By isolating these blocking tasks from the main event loop, this hook allows the Scheduler to maintain better responsiveness. This addition offers an efficient way to handle tasks that cannot run asynchronously within the event loop itself, leveraging multi-threading where necessary to keep Fibers running smoothly and minimize blocking impact. 

 ## Example 

 ```ruby 
 require "zlib" 
 require "async" 
 require "benchmark" 

 DATA = Random.new.bytes(1024*1024*100) 

 duration = Benchmark.measure do 
   Async do 
     10.times do 
       Async do 
         Zlib.deflate(DATA) 
       end 
     end 
   end 
 end 

 # Ruby 3.3.4: ~16 seconds 
 # Ruby 3.4.0 + PR: ~2 seconds. 
 ``` 

Back