레일에서 TimeWithZone 객체를 게으름으로 만들기

ActiveSupport::TimeWithZone을 더 빠르게 만들거나 게으 르게 만드는 방법은 무엇입니까?레일에서 TimeWithZone 객체를 게으름으로 만들기

필자는 필자의 레일 애플리케이션을 프로파일 링 해왔다. 그리고 나는이 TimeWithZone 오브젝트를 구성하는 데 CPU 시간의 3 분의 1이 소비된다는 것을 발견했다. 나는이 일을 끝내고있다. 겉으로보기에는 단순한 시간 대상물이 너무 비싸서 구성 할 수있는 방법은 무엇일까요? 나는 평범한 구식 Time 객체 생성을 벤치마킹하고 빠르게 TimeWithZone 건설보다는 크기 순서로 그것을 발견

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

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)

요청 당 bazillion 번 실행되는 코드입니다

프로그래밍 방식으로 모든 모델의 datetime 특성을 평범한 (값이 싼) 개체 인 느린 TimeWithZone 개체로 바꿀 수있는 방법이 있습니까? 그들은 시간이 그들이 TimeWithZone 객체로 바뀌었을 때 사용됩니까? 이것은 루비 능력을 훨씬 뛰어 넘습니다.

출처

2012-04-06 guidoism

생산 모드 – 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

이 질문에 대해 나를 때리는 것은 deserialize_from_cache(json)에서 집중하고있는 코드가 호출되고 있다는 것입니다. 왜 은이 그렇게 자주 호출되는 이유는 무엇입니까? 어쩌면 호출 체인을 더 자세히 살펴보고 json-to-time 구문 분석의 양을 줄일 수 있는지 알아볼 수 있습니까?

출처

2012-04-06 12:27:18

레일에서 TimeWithZone 객체를 게으름으로 만들기

답변

관련 문제