Issue #21532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Feature #21532: Define most of Pathname in Ruby code https://bugs.ruby-lang.org/issues/21532 * Author: Eregon (Benoit Daloze) * Status: Open * Assignee: Eregon (Benoit Daloze) ---------------------------------------- There was discussion in #17473 and before to define most of Pathname in Ruby code and not in the C extension. I have made a PR to achieve that: https://github.com/ruby/pathname/pull/57 I would like to merge it soon to avoid conflicts. Once upon a time, Pathname was pure-Ruby: https://github.com/ruby/ruby/blob/95bc02237635d3fe42532bfe53038257575cee75/l... This PR goes back to that, and reuses that original Ruby code, but keeps the C extension implementation of `<=>` and `sub` as those two are significantly faster. The other Pathname methods are actually faster in Ruby than in C, because all these methods just do `rb_funcall()` and `rb_ivar_get()` and those in C code have no inline cache, but the corresponding method calls and `@path` have inline caches in Ruby code. https://railsatscale.com/2023-08-29-ruby-outperforms-c/ is an explanation of that. Therefore having Pathname defined in Ruby seems a clear win for many reasons: * Much clearer implementation, so easier to read what the code does * Easier to maintain * Safer (no risk of accessing out of bounds memory or e.g. passing the wrong number of arguments to `rb_funcall`) * Actually faster, because of these inline caches, see numbers at the end of https://github.com/ruby/pathname/pull/57#issue-3234862768 * Better for JITs as they can optimize this, notably `...` vs the C extension being a blackbox * Works on JRuby (which does not support C extensions) * Faster on TruffleRuby (where a C extension for this is inefficient as it causes needless Ruby->C->Ruby transitions) -- https://bugs.ruby-lang.org/