2
ActiveSupport::TimeWithZoneをもっと速く構築するか怠惰にするか？RailsでTimeWithZoneオブジェクトを怠惰にする
私はRailsアプリケーションのプロファイリングを行っており、CPU時間の3分の1がこれらのTimeWithZoneオブジェクトの作成に費やされていることがわかりました。私はこれを知っている。一見単純な時間オブジェクトが構築するのに非常に高価になる可能性はどうですか？ここで
は、リクエストごとにbazillion回実行されるコードです：
def deserialize_from_cache(json)
attributes = ActiveSupport::JSON.decode(json)
attributes.keys.to_a.each do |k|
v = attributes[k]
if v.is_a? Array and v.length == 2 and v[0] == 'Time'
attributes[k] = Time.at(v[1]).in_time_zone # This is the expensive code
end
end
self.allocate.init_with('attributes' => attributes)
end
私は、昔ながらのTimeオブジェクトの構築をベンチマークし、それが速くTimeWithZone建設よりも大きさの順であることが判明：
puts Benchmark.measure { 200000.times { Time.at(1330367843) } }
0.070000 0.000000 0.070000 ( 0.068956)
puts Benchmark.measure { 200000.times { Time.at(1330367843).in_time_zone } }
0.720000 0.000000 0.720000 ( 0.715802)
モデルのすべての日時属性を、普通の古い（安価な）TimeWithZoneというオブジェクトでプログラムで置き換えることができるかどうかは、Timeまでです彼らはTimeWithZoneオブジェクトになっている時に使用されますか？これは私のRubyの能力をはるかに超えています。
製造モード – guidoism
私のラップトップ（Thinkpad Ubuntu 11.10 Ruby 1.9.3 p125、Rails 3.2.3）ではベンチマーク結果がかなり異なっています。 #atメソッドと#in_time_zoneはほとんど同じ時刻に表示されます。あなたのコードからの結果：Time.at：0.060000 0.000000 0.060000（0.054021）; Time.at.in_time_zone：0.120000 0.000000 0.120000（0.115737） – joelparkerhenderson