큰 Rails 뷰를 더 작은 부분으로 나누는 것에 대해 걱정하는 사람들의 이야기를 들었습니다. 부분을 렌더링하는 데 실제로 시간이 얼마나 걸리나요? 부분 호출의 성능 영향이 코드 가독성의 이점을 능가합니까?
나는 부분 렌더링이 인라인 렌더링과 얼마나 비교되는지에 대한 예를 제공하기 위해 몇 가지 수치를 실행했습니다. 그래서 나중에 절충점에 대해 논의할 수 있습니다. 이것은 새로운 Rails 앱에서 벤치마킹하는 데 사용한 코드입니다( config.cache_classes = true 포함). ):
<% require 'benchmark'
Benchmark.bmbm do |x|
x.report "inline" do
10000.times do -%>
<p>Hello!</p>
<% end
end
x.report "partial" do
10000.times do -%>
<%= render partial: "hello" %>
<% end
end-%>
<% end -%>
<p>Hello!</p>
결과(2013년 15인치 Retina Macbook Pro에서 Ruby 2.1 및 Rails 4.0.2 사용):
Rehearsal -------------------------------------------
inline 0.010000 0.000000 0.010000 ( 0.007045)
partial 0.970000 0.090000 1.060000 ( 1.050433)
---------------------------------- total: 1.070000sec
user system total real
inline 0.010000 0.000000 0.010000 ( 0.005529)
partial 0.920000 0.070000 0.990000 ( 0.997491)
따라서 부분 렌더링은 빠른 시스템에서 평균 약 0.1ms로 실행됩니다. 인라인으로 렌더링하는 것보다 훨씬 느리지만 URL 생성, Rails 도우미 및 브라우저 렌더링 시간과 같은 사항에 대해 생각할 때 알아차리기 어려울 정도로 빠릅니다.
속도가 전부는 아닙니다
부분 렌더링의 성능이 훨씬 더 나빴다면 나는 여전히 거대한 뷰를 분해하기로 결정했을 것입니다.
Make It Work, Make It Right, Make It Fast라는 문구가 있습니다. 너무 큰 보기를 수정하려고 할 때 "작동하기" 모드에서 벗어나려고 하고 "빠르게 만들기"로 건너뛸 수 없습니다. 코드를 유지 관리하기 어렵게 만들고 리팩토링을 위한 몇 가지 기회를 놓칠 수 있습니다. 이는 캐싱 기회로 이어질 수 있으며, 이는 더 큰 성능 이점으로 이어질 수 있습니다.
측정하기 전에는 알 수 없습니다
내 숫자를 믿을 필요는 없습니다. 나는 당신이하지 않는 것이 좋습니다! Ruby의 Benchmark 라이브러리는 자체 벤치마크를 실행할 수 있는 몇 가지 간단한 도구를 제공합니다. New Relic 및 MiniProfiler와 같이 전체 스택을 프로파일링하는 도구도 있습니다. 저는 일상 업무에서 이 세 가지를 모두 정기적으로 사용합니다.
프로파일링할 때 항상 프로덕션 모드에서 프로파일링하십시오! Rails 개발 환경은 클래스와 뷰를 자동으로 다시 로드하므로 개발하는 동안 유용하지만 성능이 저하됩니다.