From: "byroot (Jean Boussier) via ruby-core" Date: 2025-12-03T14:55:20+00:00 Subject: [ruby-core:124006] [Ruby Feature#21721] Allow `Queue` and `SizedQueue` to be used as LIFO queues Issue #21721 has been updated by byroot (Jean Boussier). > ConditionVariable and Mutex are too slow on CRuby. So I looked at `Mutex` and `Monitor` for now. I found an easy win for all `TypedData` which helps a bit: https://github.com/ruby/ruby/pull/15387 Before: ``` Mutex 13.548M (� 3.6%) i/s (73.81 ns/i) - 68.566M in 5.067444 Monitor 10.497M (� 6.5%) i/s (95.27 ns/i) - 52.529M in 5.032698s ``` After: ``` Mutex 20.887M (� 0.3%) i/s (47.88 ns/i) - 106.021M in 5.075989s Monitor 16.245M (�13.3%) i/s (61.56 ns/i) - 80.705M in 5.099680s ``` But beyond that, profiling show that the major hotspot is `rb_current_ec_noinline()` and `rb_current_execution_context()`, at 10% and 5% respectively. But there are some scary comments in there, so I'm not really confident I can find optimizations there without introducing a subtle bug. I do however have another commit that tries to call `rb_fiber_current` less, with modest gains: https://github.com/byroot/ruby/commit/54e9e7242a1dcfa7a403f36e91585804d9944f42. I'll try to find some more time to look at `ConditionVariable` but I'm not super confident we can come close to `Queue`. ---------------------------------------- Feature #21721: Allow `Queue` and `SizedQueue` to be used as LIFO queues https://bugs.ruby-lang.org/issues/21721#change-115436 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context Since `Queue` and `SizedQueue` gained a proper timeout mechanism, I've been wanting to use them to implement simpler and more efficient connection pools. However for connection pools you ideally want a LIFO queue because it's preferable to checkout the most recently used connection. ### Problem Both `Queue` and `SizedQueue` only support FIFO because you can only enqueue elements at the beginning of the backing array, and only dequeue at the end. `Queue#push` (aliased as `Queue#<<` and `Queue#enq`) calls `Array#unshift` on the backing array and `Queue#pop` (aliased as `Queue#deq` and `Queue#shift`) calls `Array#pop`. Hence it is impossible to use these two classes for anything other than FIFO queues. I tried to use `git blame` to see if there was a justification for this, but I ended up in a git blame loop around May 2000 https://github.com/ruby/ruby/commit/9da4f78db46764be6dae5e7e83ff48cbecb3fb23 ### Feature I'd like to introduce either of two new methods (or both) to allow for LIFO: - A method to dequeue from the beginning of the backing array (`array_shift`). - A method to enqueue from the end of the backing array (`array_push`). A difficulty I have however is that since the common `shift/pop/push` terms are already used with uncommon meaning, it's hard to come up with good names. Ideas welcome. ### Possible alternatives - Define different classes for LIFO queues - But I find that less flexible, and it means exposing new constant names in the global namespace. - Add an initializer argument to define the queue ordering, e.g. `Queue.new([], lifo: true)` - Similarly, I find this less flexible than to decide the order during enqueue/dequeue - Add an argument to `Queue#pop` and `Queue#push`, e.g. `queue.push(element, front: true)`. -- https://bugs.ruby-lang.org/ ______________________________________________ ruby-core mailing list -- ruby-core@ml.ruby-lang.org To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.ruby-lang.org/