Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
Until Ruby 3.2 the `is_a?` method can be a surprising performance bottleneck. It be called directly or through its various synonyms like case statements, rescue statements, protected methods, `Module#===` and more! Recently `is_a?` and its various flavours have been optimized and it's now faster and runs in constant time. Join me in the journey of identifying it as a bottleneck in production, implementing the optimization, squashing bugs, and finally turning it into assembly language in YJIT.
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In his talk "Making .is_a? Fast" at RubyConf 2022, John Hawthorn discusses the performance bottleneck associated with the `is_a?` method in Ruby, which checks an object's class or module membership. Despite its frequency of use in Ruby applications—accounting for roughly two percent of total runtime—the performance of `is_a?` has historically fallen short of expectations. Hawthorn begins by explaining the `is_a?` method's functionality, illustrating its usage with simple examples involving class checking. He emphasizes that profiling is essential for identifying performance issues, stating that in certain production environments, the `is_a?` method can consume up to four percent of runtime. Key points from Hawthorn's presentation include: - **Profiling Tools**: He recommends tools like `stack Prof` and `rbspy` for performance profiling, revealing that multiple methods, including `===` and case statements, contribute to runtime overhead. - **Performance Analysis**: He analyzes how Ruby’s checking of class ancestry can be inefficient due to issues like linked list structures causing increased time for checks, particularly when classes include multiple modules, which can complicate the ancestor hierarchy. - **Proposed Solutions**: Hawthorn suggests enhancing the implementation of `is_a?` to achieve constant time performance, which involves reworking the Ruby VM to optimize this method by reducing reliance on iterative checks. - **Memory Optimization**: The approach includes the usage of a hash to manage class ancestors efficiently, which not only streamlines checks but also reduces overall memory usage. - **Community Engagement**: He urges the Ruby community to engage in performance profiling and to contribute insights that can benefit the ecosystem. Hawthorn concludes by highlighting the significant improvements made through these optimizations, which allow Rails applications to operate more efficiently. His call to action encourages collective efforts in enhancing Ruby's performance landscape, particularly through profiling and optimization strategies that simplify the use of `is_a?` without disrupting existing application logic.
Suggest modifications
Cancel
