14

私はt_time_tracker (woohoo!) と呼ばれる最初の gem を開発しています。開発は順調に進んでいました。実行時間をできるだけ短縮するために、可能な限り最適化しました。

t_time_tracker[master*]% time ruby -Ilib ./bin/t_time_tracker 
You're not working on anything
0.07s user 0.03s system 67% cpu 0.141 total

(これは私のアプリの「Hello World」です。パラメーターなしで呼び出すと、「You're not working on anything」と表示されます)

約 10 分の 1 秒で、CPU の 67% を使用します。これで十分です。割とあっさりした感じです。それを構築しましょう:

$ gem build t_time_tracker.gemspec
$ gem install ./t_time_tracker-0.0.0.gem

そして、インストールされたバイナリでまったく同じことを行います:

$ time t_time_tracker
You're not working on anything
t_time_tracker  0.42s user 0.06s system 93% cpu 0.513 total

0.5秒?!それはどこから来ましたか?!デバッグ出力を追加し、開発バイナリのシステム gem を含めて、ボトルネックがどこにあるかを確認してみましょう。

t_time_tracker[master*]% time ruby ./bin/t_time_tracker  
(starting binary)
(require 'time' and 'optparse')
0.041432
(before `require 't_time_tracker')
0.497135
(after `require 't_time_tracker')
(Gem.loaded_specs.keys = t_time_tracker)
(initializing TTimeTracker class)
You're not working on anything
ruby ./bin/t_time_tracker  0.44s user 0.07s system 91% cpu 0.551 total

よし、'require 't_time_tracker' 行が原因のようだ。irb でもう一度試して、さらに絞り込みましょう。

$ irb
>> t=Time.now; require 't_time_tracker'; puts Time.now-t
0.046792
=> nil

...何?しかし、それには 0.5 秒しかかかりませんでした。デバッグ出力を使用して gem をビルドしてみましょう。

$ gem build t_time_tracker.gemspec
$ gem install ./t_time_tracker-0.0.0.gem
$ time t_time_tracker
(starting binary) <---noticeable half second delay before this line shows up
(require 'time' and 'optparse')
0.050458
(before `require 't_time_tracker')
0.073789
(after `require 't_time_tracker')
(Gem.loaded_specs.keys = t_time_tracker)
(initializing TTimeTracker class)
You're not working on anything
t_time_tracker  0.42s user 0.06s system 88% cpu 0.546 total

ええ、この 0.5 秒の遅延はどこから来ているのでしょうか? 私は普段は気にしませんが、これは私がやっていることを更新するために 1 日に約 50 回電話をかけていることです。50 * 0.5 秒 * 365 日 * 70 年 = 失われた 15 日。

システムインフォメーション:

Mac OS X 10.7.3。2 GHz インテル Core 2 Duo。4GBのラム。ルビー 1.9.2p290。

% gem -v
1.8.10<---noticeable half second delay before this line shows up
% gem list | wc -l
209
4

3 に答える 3

2

これを見てからしばらく経ちましたが、RubyGems は過去 (そしておそらく現在) に、主に 2 つの理由でロードに時間がかかりました。

  • 「yaml」を介して「time」などの多くの比較的高価なライブラリをロードします。通常は、Ruby 自体に比べて遅く、多くのスクリプトの実行時間に比べて遅くはないため、気にする必要はありません。
  • インストールされているすべての gem をスキャンし、最新の gemspec をメモリにロードします。宝石がたくさんある場合、これには長い時間がかかりました。

これらの問題は、まだ解決されていない可能性があります。ただし、常にRubyGems からのオーバーヘッドが発生します。本当にパフォーマンスが必要な場合は、自分でロード パスを設定してください。ご存じのとおり、RubyGems を使用しない Ruby は非常に高速です。

gem がインストールされている場所を確認するには:

gem list -d YOUR_GEM_NAME

インストールディレクトリが表示されます。あなたの宝石は INSTALL_DIR/gems/GEM_NAME-VERSION にあるので、実行してみてください:

time ruby -IINSTALL_DIR/gems/GEM_NAME-VERSION/lib INSTALL_DIR/gems/GEM_NAME-VERSION/bin/t_time_tracker

それはたくさんありますが、これを次のような別のスクリプトでラップできるはずです (名前は t_time_tracker):

#!/usr/bin/env ruby -IINSTALL_DIR/gems/GEM_NAME-VERSION/lib
load 'INSTALL_DIR/gems/GEM_NAME-VERSION/bin/t_time_tracker'

それで:

chmod +x t_time_tracker
time ./t_time_tracker

そして、そのファイルを PATH に沿った任意の場所に置きます。RubyGems は自動的に実行しますが、もちろん RubyGems のオーバーヘッドを受け入れます。

于 2012-07-12T16:03:33.523 に答える
0

gem 内で使用$LOAD_PATHされていることが原因である可能性があります。理想的には、フォルダーのパスはlibそのアレイの最初です。

于 2012-05-31T06:59:49.973 に答える
-1

それはおそらくあなたがそれを「地元の」宝石から持っているからでしょう。したがって、ルビーは彼を迎えに行く前に他の道をチェックする必要があります。

例えば。json.rbというファイルとjsonというグローバルにインストールされたgemがある場合

require 'json' 

彼は最初の宝石を見つけてロードします:)。ローカルパスが最後にロードされます。gemをバンドルしてインストールすると、gem内の場所が異なるため、速度が大幅に向上します。開発中のこのロード時間の不足についてはあまり心配しません。

于 2012-05-30T08:49:11.640 に答える