#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
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
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
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
