タグ

RubyとBenchmarkに関するYassLabのブックマーク (15)

  • Redis不要のSolid QueueはSidekiq OSSに勝てるのか?Rails 8で非同期処理を徹底比較

    背景と目的 Rails8.0 ではActive Jobの機能が拡充されたことに加え、これまでの Sidekiq や Resque などに加えて、新たに Solid Queue という選択肢が提示されました。しかしながら、Sidekiq の公式ドキュメントでは以下のような性能差が示唆されています: Active Job 経由と Sidekiq ネイティブ使用で 約1.2倍の差 Solid Queue と比較すると 最大15倍の差 果たしてこれらの差は現実にどの程度再現されるのか? また、Solid Queue を使う場合に Sidekiq に並ぶ性能を発揮するにはどのような設定が必要なのか? OSS ライセンスの範囲内で各方式の性能を定量的に検証しました。 実験環境 実験環境としては筆者のPCにてDocker Desktopのコンテナを利用しました。 Ruby: 3.3.5 Rails: 8

    Redis不要のSolid QueueはSidekiq OSSに勝てるのか?Rails 8で非同期処理を徹底比較
    YassLab
    YassLab 2025/05/23
    “Solid Queueも、スレッド数やプロセス数を適切に調整すれば十分に実用に耐える性能を発揮することがわかりました。 特に新規プロジェクトで Redis を導入せずに構成をシンプルにしたいケースでは、有力な選択肢”
  • Fast Allocations in Ruby 3.5

    Many Ruby applications allocate objects. What if we could make allocating objects six times faster? We can! Read on to learn more! Speeding up allocations in Ruby Object allocation in Ruby 3.5 will be much faster than previous versions of Ruby. I want to start this article with benchmarks and graphs, but if you stick around I’ll also be explaining how we achieved this speedup. For allocation bench

    Fast Allocations in Ruby 3.5
    YassLab
    YassLab 2025/05/23
    “Object allocation in Ruby 3.5 will be much faster than previous versions of Ruby. I want to start this article with benchmarks and graphs, but if you stick around I’ll also be explaining how we achieved this speedup. ”
  • #RubyKaigi 2025 で「Improvement of REXML and speed up using StringScanner 」というタイトルで発表しました - @naitohの日記

    2025/04/16〜2025/04/18にかけて松山で開催されたRubyKaigi 2025に参加し、今回は RubyKaigi 編に登壇するという実績を解除することができました🎉 rubykaigi.org 昨年の RubyKaigi 2024 のLT でお話した話 naitoh.hatenablog.com の続きで、今回、発表した資料は下記になります。 slide.rabbit-shocker.org ベーンチマークコード ベンチマーク結果 REXML 3.2.6 (Ruby 3.3.0 添付のもの) から最新の REXML 3.4.1 の間で、StringScanner を使った実装に置き換える事で、XMLパース処理が最大6割速くなったので、 StringScanner を使うと何故パース処理が速くなるのか、どのような点に気をつけてパース処理を書けば速くなるのか などを、RE

    #RubyKaigi 2025 で「Improvement of REXML and speed up using StringScanner 」というタイトルで発表しました - @naitohの日記
    YassLab
    YassLab 2025/04/21
    “XMLパース処理が最大6割速くなったので、 StringScanner を使うと何故パース処理が速くなるのか、どのような点に気をつけてパース処理を書けば速くなるのか などを、REXML の実装を踏まえながら高速化のポイントを紹介”
  • 「RailsアプリはIO-boundである」という神話について考える(翻訳)|TechRacho by BPS株式会社

    概要 原著者の許諾を得て翻訳・公開いたします。 英語記事: The Mythical IO-Bound Rails App | byroot’s blog 原文公開日: 2025/01/23 原著者: byroot -- Railsコアコミッター、Rubyコミッターであり、ShopifyのRuby/Railsインフラチームのシニアスタッフエンジニアです 日語タイトルは内容に即したものにしました。 IO-boundは英ママとしました。 私がやりたいのは、Pitchfork1に関する記事を書いて、これがどんな理由でできたのか、なぜ現在のような形になったのか、そして今後どうなるのかについて説明することです。しかしその前に、いくつか解説しておく必要があります。 Railsとパフォーマンスの話題になると「データベースがボトルネックになる」という話がよく持ち上がりますが、RailsはいずれにしてもI

    「RailsアプリはIO-boundである」という神話について考える(翻訳)|TechRacho by BPS株式会社
    YassLab
    YassLab 2025/02/19
    “より効率的な方法があるかどうかを誰もプロファイラでチェックしなかったといった理由で、Rubyコードが目に見えて遅くなってしまう可能性もある / 使い勝手とパフォーマンスは必ずしも相反するものではありません”
  • Railsの起動時間を7分の1にした話|taogawa

    こんにちは。2021年12月にCAMPFIREに入社した小川です。 CAMPFIREではRailsを使って開発しています。わたしの入社後、いくつかRailsのパフォーマンスチューニングをする機会があったのですが、今回はそのうち、開発環境でのRailsの起動時間を約7分の1に短縮することができた事例についてご紹介したいと思います。 Railsの起動が遅いCAMPFIREで開発をしはじめてひとつ気づいたのが、開発環境でのRailsの起動にやけに時間がかかることでした。計測してみると1分以上かかっています・・・。 $ time bundle exec rake environment # ... real 1m10.845s user 0m8.075s sys 0m2.086s これは遅い。アプリケーションの規模はたしかに大きいのですが、それを加味しても遅すぎる印象です。 チームメンバーに尋ねて

    Railsの起動時間を7分の1にした話|taogawa
    YassLab
    YassLab 2025/02/17
    "速度改善においては、まず大まかなプロファイリングでボトルネック箇所を特定し、そこからより具体的に箇所を特定していくとやりやすい / BumblerはRailsの起動周りで大まかなボトルネック箇所のプロファイリングに便利"
  • Optimizing Ruby’s JSON, Part 4

    In the previous post, we established that as long as ruby/json wasn’t competitive on micro-benchmarks, public perception wouldn’t change. Since what made ruby/json appear so bad on micro-benchmarks was its setup cost, we had to find ways to reduce it further. Spot the Seven Differences So I decided to file this performance discrepancy as a bug, and investigate it as such and started profiling Step

    YassLab
    YassLab 2025/01/01
    "with all the above optimizations, we were now faster than Oj when reusing the JSON::State object, but still quite a bit slower when allocating it on every call ... So there was no way around it, I had to find how to automatically re-use that JSON::State object. Or how to not allocate it at all?"
  • Optimizing Ruby’s JSON, Part 3

    In the previous post, I covered how I reimplemented JSON::Generator::State#configure in Ruby and some other changes. Unfortunately, it didn’t go as well as I initially thought. Mistakes Were Made The default gems that ship with Ruby are automatically copied inside ruby/ruby’s repo. In short, there’s a bot aptly named matzbot, that replicates all the commits from the various ruby/* gems, inside rub

    YassLab
    YassLab 2025/01/01
    “In the next post, we’ll dive into how the setup cost was optimized further, and then at some point, we’ll have to start talking about optimizing the parser.”
  • Optimizing Ruby’s JSON, Part 2

    In the previous post, I covered my motivations for improving ruby/json’s performance, and detailed the first 4 notable optimizations applied to speed up JSON generation. If I was to cover every single optimization applied, at this rate I’d end up with a dozen parts, so I’ll try to only focus on the one that made a significant difference or used an interesting pattern. Reducing Setup Cost - Argumen

    YassLab
    YassLab 2025/01/01
    “At this rate, and based only on the number of commits I haven’t yet covered, I may need 5 or 6 more parts, but I hope I won’t have to disgress as much as the series progress, and not all commits may be worth talking about. Edit: Part three is here.”
  • Optimizing Ruby’s JSON, Part 1

    I was recently made maintainer of the json gem, and aside from fixing some old bugs, I focused quite a bit on its performance, so that it is now the fastest JSON parser and generator for Ruby on most benchmarks. Contrary to what one might think, there wasn’t any black magic or deep knowledge involved. Most of the performance patches I applied were fairly simple optimizations driven by profiling. A

    YassLab
    YassLab 2025/01/01
    “I have way more optimizations than these ones to talk about, but I feel like it’s already a pretty packed blog post. So I’ll stop here and work on some followup soon, hopefully I won’t lose my motivation to write :). / Edit: Looks like I didn’t, part two is here.”
  • 【Rails7】パフォーマンス測定ヘルパー「benchmark」で、特定の処理の速度を測ってみる

    #db/seeds.rb User.create!( name: "kamekame", email: "example-1@practice.com", password: "password", password_confirmation: "password" ) 700.times do |n| Post.create!( title: Faker::Music.band, content: "example-#{n+1}", user_id: 1 ) end ②benchmarkヘルパーをcontrollerに埋め込む 今回は、 ①posts#indexにアクセスし、@posts = current_user.posts.order(created_at: :desc)の処理を終えるまでにかかる時間 ②posts#showにアクセスし、@post = current_user.p

    【Rails7】パフォーマンス測定ヘルパー「benchmark」で、特定の処理の速度を測ってみる
    YassLab
    YassLab 2024/12/20
    “Railsを学ぶ中で、処理速度の測定に興味を持ちました。 調べていくと、Railsで使用することのできる「benchmarkヘルパー」を見つけたため、実際に試してみました。”
  • Speeding up Ruby by rewriting C… in Ruby

    There is a recent language comparison repo which has been getting shared a lot. In it, CRuby was the third slowest option, only beating out R and Python. The repo author, @BenjDicken, created a fun visualization of each language’s performance. Here’s one of the visualizations, which shows Ruby as the third slowest language benchmarked: The code for this visualization is from https://benjdd.com/lan

    Speeding up Ruby by rewriting C… in Ruby
    YassLab
    YassLab 2024/12/08
    “With a layer like YJIT, it potentially opens up a future where more of the language becomes plain Ruby, and Ruby developer contribution is easier. Many languages have a smaller low level core, and the majority of the language is written in itself. Maybe that’s a future for CRuby, someday!”
  • Ruby might be faster than you think - John Hawthorn

    I saw a project a couple weeks back which allows writing and running Crystal methods inline inside a Ruby file. It’s a neat project, and I don’t want to take away from it but something in the README example looked off to me. require 'crystalruby' require 'benchmark' module Fibonnaci crystalize [n: :int32] => :int32 def fib_cr(n) a = 0 b = 1 n.times { a, b = b, a + b } a end module_function def fib

    YassLab
    YassLab 2024/05/04
    “Now it’s Ruby that’s 5 times faster than Crystal!!! And 20x faster than our original version. Though most likely that’s some cost from the FFI, or something similar, though that does seem like a surprising amount of overhead. ”
  • Is my host fast yet?

    Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web. Leaderboard: November 2024 Looking for the latest data? Check out the HTTP Archive Tech Report Sort by Client Host Client Websites Fast (p75 < 800ms) Average Slow (p75 >= 1800ms) See a missing hosting provider? Please help us identify how to surface them here. How do you measure real-w

    YassLab
    YassLab 2024/05/02
    “Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web. ”
  • https://twitter.com/tobi/status/1785651701858394334

    YassLab
    YassLab 2024/05/02
    “Good, but we can do better.”
  • Goで作ったシステムをRubyでリプレイスすることを検討してみた

    はじめに 弊社にはGoで作ったシステムが存在しますが、作られてから数年が経過して、メンテナンスも十分にできていない状況でした。 そこで、このシステムをリファクタリングして生産性を上げようという結論になりました。 リファクタリングにあたり、Goのままで行くのか、弊社でよく使われているRubyで行くのかを検討してみましたので、その過程を紹介したいと思います。 Rubyでリプレイスしようと思った理由 Goで動いてて言語やライブラリのバージョンアップなどメンテナンスがされてない部分はありますが、 そこを解消すればGoのままで行った方が良いのでは?と思うかもしれません。 しかし、あえてRubyでリプレイスしようと思うに至ったのは以下の点があります。 Rubyの方が開発速度があがりそう Goのリファクタリングをするのに時間がかかりそう Goのリファクタリングと機能追加でコード修正箇所が被るとスケジュー

    Goで作ったシステムをRubyでリプレイスすることを検討してみた
    YassLab
    YassLab 2024/05/01
    "実装に掛かった時間は1日程度 / Goのコード量は1,000行を超える / Rubyでは300行ほど / やはりAPIとDBの処理時間が全体の大半を占めている / 処理時間に大きな差が発生してない / CPUリソースは多く使いそうなのでその点は考慮”
  • 1