Ruby の JSON ライブラリ Oj のパフォーマンス改善を行いました - Repro Tech Blog
Development Division/Repro Team/Feature 1 Unit の Watsonです。Feature 1 Unit は Repro Tool の機能開発と保守を担っています。 弊社でも利用している Oj gem のパフォーマンス改善 PR を送った話と、その PR の内容について共有します。 ことのはじまり 以前、同僚が Ruby on Rails で JSON を返す REST API を作成した際、JSON のエンコード部分のパフォーマンス計測をしていました。JSON のエンコード方法は JSON.generate、ActiveSupport::JSON.encode、Oj gem を利用する方法など色々ありますが、私としては Oj gemの ほうがパフォーマンス的にいいだろうからそちらを利用したほうが良いのではと思っておりました。 計測結果を拝見したら確
rr: lightweight recording & deterministic debugging
what rr does rr aspires to be your primary C/C++ debugging tool for Linux, replacing — well, enhancing — gdb. You record a failure once, then debug the recording, deterministically, as many times as you want. The same execution is replayed every time. rr also provides efficient reverse execution under gdb. Set breakpoints and data watchpoints and quickly reverse-execute to where they were hit. rr
「この位置にｐｒｉｎｔｆが無いとなぜか動かないんだ。」 - Qiita
はじめに 先日ツイッターで見かけた呟き pic.twitter.com/33Yk02hu1U — TOMO (@tomozh) October 14, 2020 そういうこともあるのか的な反応もあるようなので具体例を挙げてみることにする。 例1 所謂FizzBuzz問題。 #include <stdio.h> void fizzbuzz(int n) { int next; int i = 1; do { printf(i % 15 ? i % 5 ? i % 3 ? "%d\n" : "Fizz\n" : "Buzz\n" : "FizzBuzz\n", i); if (i++ >= n) next = 0; } while (next); } int main(void) { printf((char[]){""}); // この位置にprintfが無いとなぜか動かない fizzbuz
バッファキャッシュとAIO（1）
プロセスがブロックする要因の一つにファイルI/Oがあります。これを同期I/Oと言いますが、POSIXではAIO（非同期 I/O、Asynchronous I/O）も定義しており、I/O中でもプロセスがブロックせず他の処理を進められるようになります。 本記事ではバッファキャッシュからファイル I/Oを解説し、Linuxのio_submit(2)を用いたPOSIX準拠のAIOライブラリを試作してみます。 ファイルI/Oとバッファキャッシュ io_submit(2)ではDirect I/Oを用いますが、ライブラリの試作へ進む前にまずファイルI/Oのバッファ（バッファキャッシュ）について整理します。実は単にバッファと言ってしまうと誤解される場面が多くあり、例えばプログラミング入門一般としてファイルI/Oを取り上げる際には、 CPUの動作は速い。ディスクの動作は遅い。 両者の間に速度差を緩和する緩衝
enbug diary(2006-07-14) - failmalloc
_ failmalloc 私は立場上いろんな人のプログラムを見る必要がある。 しかし、とりわけ経験不足な人が書いたコードはエラーチェックが無茶苦茶である。 要するに、失敗することを考えていない。 これには非常にうんざりさせられるが、 そもそも何が原因なのか考えてみた。 失敗するのを見ることがないのがいけない。 これが私の辿り着いた結論である。 実のところ、malloc が本当にこけるところなんて、熟練者でさえ滅多に見たことがないんじゃなかろうか。 今日のようにメモリが潤沢になると、その傾向にますます拍車がかかることになる。 そこで、いっそのこと、わざと失敗させてみることにした。 何で今までこういうものがなかったのか、多少不思議ではあるが （私が知らないだけ？）、 30分ぐらいのハックで出来上がった。 それよりウェブページを作成する方がよっぽど時間がかかってしまった。 詳細はウェブの方を見て
Cのプログラムの中でブレークポイントを設定する - bkブログ
Cのプログラムの中でブレークポイントを設定する Cのプログラムをデバッグする際には GDB などのデバッガが役立ちます。通常、ブレークポイントはデバッガの中から設定しますが、デバッグ対象のCのプログラムの中で設定することもできます。 Linux なら #include <signal.h> して、任意の箇所に raise(SIGTRAP); を挿入すれば OK です。 raise() 関数を用いて SIGTRAP シグナルを発生させています。 あるいは x86 限定なら __asm__("int3"); でも OK です。ここでは SIGTRAP を発生させるために int3 (0xcc) 命令を埋め込んでいます。GDB もソフトウェア的にブレークポイントを設定するときは当該箇所に int3 を書き込んでいるので、やっていることは割と似ています (GDBの場合は int3 を書き込む部分の
投機実行とOut of Orderはつよいというはなし - なるせにっき
fluentdな人達と話していると定期的にRubyのオブジェクト生成が遅いとdisられます。 本質的にしょうがない部分もあるんですが、それにしても遅い部分も結構あるので、おもむろにperf statとperf recordを取ってみましょう。 % sudo perf stat -d ./miniruby -e'GC.disable;i=1000000;while (i-=1)>0;Hash.new;end' Performance counter stats for './miniruby -eGC.disable;i=1000000;while (i-=1)>0;Hash.new;end': 467.629812 task-clock (msec) # 0.993 CPUs utilized 19 context-switches # 0.041 K/sec 2 cpu-migratio
C言語分かってなかった (I Do Not Know C) - Qiita
Dmitri Gribenko氏によるBlog記事 "I Do Not Know C" より訳出。原文および訳文のライセンスは CC BY-SA 3.0 に従う。 この記事の目的は、皆に（とくにCプログラマに）「C言語分かってなかった」と言わせることです。 C言語の死角は思っているよりも身近にあり、よくある単純なコードですら 未定義動作(undefined behavior) を含む可能性があると示したいと思います。 記事は質問に対する回答の形をとります。全ての例示コードは別々のファイルに分かれていると考えてください。 （訳注：Qiita/Markdown表現の制約から、読中ネタバレ防止のため文章順序を変更しています。前半には質問のみを、後半には質問と回答の対を訳出しました。） 質問編 1.
古のテクニックを見せようと思ったら最近の技術の前にあっさり敗北した話
オブジェクトについて抽象から具象まで取り混ぜて説明していた時、最も具象なレベルで見れば、オブジェクトはメモリ上に確保した領域にすぎないと説明しました。 そんな説明をしていた時、メソッドの実体ってどこにどうあるのですかと質問を受けました。人の心はどこにどうあるのですかという質問に比べると緩い質問ですが、良い質問だと思いました。こういう疑問を持つのは大事だと思うからです。自分もかつてプログラムとは結局のところどう実行されるのかが気になりました。プログラマなら誰もが通る道だと思います。 そんなわけでJavaのような箱入り娘から離れて、デレのないツンデレ娘ことC言語で古のテクニックを見せることにしました。 とりあえず次の簡単なコードから始めます。C言語は知らなくても構いません。関数fnがあって、引数に2を加算して返すことだけを読み取ってください。 #include <stdio.h>
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
