Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

프로파일러

Godot에서 게임을 실행하고 놀아보세요. 재미있고, 기능이 완벽해지고 있으며, 출시가 가까워지고 있다는 느낌이 듭니다.

그러나 스킬 트리를 열면 코드에 문제가 발생하면서 작동이 멈춥니다. 스킬 트리가 슬라이드 쇼처럼 스크롤되는 것을 보는 것은 용납될 수 없습니다. 무엇이 잘못되었나요? 스킬 트리 요소, UI 또는 렌더링의 위치를 지정하는 것입니까?

모든 것을 최적화하고 게임을 반복적으로 실행할 수도 있지만, 이에 대해 더 현명하게 대처하여 가능성을 좁힐 수 있습니다. Godot의 프로파일러에 들어가세요.

PCK 파일의 개요

디버거 패널을 열고 프로파일러 탭을 클릭하여 프로파일러를 열 수 있습니다.

../../../_images/profiler.png

프로파일링은 성능 집약적이기 때문에 Godot의 프로파일러는 자동으로 실행되지 않습니다. 게임에서 일어나는 모든 일을 지속적으로 측정하고 디버거에 보고해야 하므로 기본적으로 꺼져 있습니다.

프로파일링을 시작하려면 게임을 실행한 다음 다시 편집기에 집중하세요. 프로파일러 탭의 왼쪽 상단에 있는 시작 버튼을 클릭합니다. 다음에 프로젝트가 실행될 때 프로파일러가 자동으로 시작되도록 자동 시작**을 선택할 수도 있습니다. **Autostart 체크박스의 상태는 에디터 세션 전반에 걸쳐 유지되지 않습니다.

참고

프로파일러는 현재 C# 스크립트를 지원하지 않습니다. C# 스크립트는 JetBrains Rider 및 JetBrains dotTrace와 Godot 지원 플러그인을 사용하여 프로파일링할 수 있습니다.

언제든지 지우기 버튼을 클릭하여 데이터를 지울 수 있습니다. 측정하는 데이터 유형을 변경하려면 측정 드롭다운 메뉴를 사용하세요. 측정 패널과 그래프가 이에 따라 업데이트됩니다.

측정된 데이터

프로파일러의 인터페이스는 두 개로 나뉩니다. 왼쪽에는 기능 목록이 있고 오른쪽에는 성능 그래프가 있습니다.

주요 측정값은 프레임 시간, 물리 프레임, 유휴 시간 및 물리 시간입니다.

  • **프레임 시간**은 Godot가 물리에서 렌더링까지 전체 이미지에 대한 모든 논리를 실행하는 데 걸리는 시간입니다.

  • **물리 프레임**은 Godot가 물리 업데이트 사이에 할당한 시간입니다. 이상적인 시나리오에서 프레임 시간은 선택한 대로입니다. 기본적으로 16.66밀리초(60FPS에 해당)입니다. 이는 주변의 모든 것에 사용할 수 있는 참조 프레임입니다.

  • **유휴 시간**은 Godot가 `_process`에 있는 코드나 **유휴**에 업데이트되도록 설정된 타이머 및 카메라와 같은 물리 이외의 로직을 업데이트하는 데 걸린 시간입니다.

  • 물리 시간**은 Godot가 `_physics_process` 및 **물리 업데이트로 설정된 내장 노드와 같은 물리 작업을 업데이트하는 데 걸린 시간입니다.

참고

**프레임 시간**에는 렌더링 시간이 포함됩니다. 게임에서 알 수 없는 지연 급증을 발견했지만 물리학과 스크립트가 모두 빠르게 실행되고 있다고 가정해 보겠습니다. 지연은 입자나 시각 효과로 인해 발생할 수 있습니다!

기본적으로 Godot는 프레임 시간과 물리 시간을 선택합니다. 이를 통해 할당된 원하는 물리 FPS에 비해 각 프레임이 소요되는 시간에 대한 개요를 제공합니다. 왼쪽의 확인란을 클릭하여 기능을 켜거나 끌 수 있습니다. 코드가 나타나는 스크립트 함수에 도달하기 전에 물리 2D, 물리 및 오디오와 같은 다른 기능이 목록 아래로 내려갈 때 나타납니다.

그래프를 클릭하면 왼쪽에 표시되는 프레임 정보가 변경됩니다. 오른쪽 상단에는 보고 있는 프레임을 보다 세부적으로 수동으로 조정할 수 있는 프레임 카운터도 있습니다.

측정 범위 및 측정 창

측정 드롭다운 메뉴를 사용하여 보고 있는 측정을 변경할 수 있습니다. 기본적으로 프레임 시간으로 시작하고 프레임을 통과하는 데 걸리는 시간을 밀리초 단위로 나열합니다. 평균 시간은 주어진 함수가 두 번 이상 호출될 때 소요된 평균 시간입니다. 예를 들어, 5번 실행하는 데 0.05밀리초가 걸린 함수는 평균 0.01밀리초를 제공해야 합니다.

정확한 밀리초 계산이 중요하지 않고 프레임의 나머지 부분에 상대적인 시간 비율을 확인하려면 백분율 측정을 사용하세요. 프레임 시간을 기준으로 프레임 % i, 물리 시간을 기준으로 물리 % i.

마지막 옵션은 시간 범위입니다. 포함**은 중첩된 함수 호출을 **포함하여 함수에 걸린 시간을 측정합니다. 예를 들면:

../../../_images/split_curve.png

get_neighbors, find_nearest_neighbor 및 move_subject 모두 시간이 많이 걸렸습니다. 세 가지가 모두 느리기 때문이라고 착각할 수도 있습니다.

그러나 **Self**로 변경되면 Godot는 자체적으로 생성된 함수 호출을 고려하지 않고 함수 본문에서 소요된 시간을 측정합니다.

../../../_images/self_curve.png

get_neighbors 및 move_subject`가 중요성을 많이 상실한 것을 볼 수 있습니다. 실제로 이는 `get_neighbors 및 `move_subject`가 다른 함수 호출이 끝나기를 기다리는 데 더 많은 시간을 소비했으며 `find_nearest_neighbor`는 실제로 느리다는 것을 의미합니다.

프로젝트 준비하기

프로파일러를 사용하여 느린 코드를 찾는 것은 게임을 실행하고 게임이 그려지는 성능 그래프를 보는 것으로 요약됩니다. 프레임 시간에 허용할 수 없는 스파이크가 발생하면 그래프를 클릭하여 게임을 일시 중지하고 _Frame #_을 스파이크 시작 지점으로 좁힐 수 있습니다. 근본 원인을 찾으려면 프레임과 기능 사이를 앞뒤로 이동해야 할 수도 있습니다.

스크립트 기능에서 일부 기능에 대한 확인란을 켜서 시간이 걸리는 기능을 찾습니다. 검토하고 최적화해야 하는 기능은 다음과 같습니다.

마이크로초 단위로 수동 측정

기능이 복잡한 경우 최적화가 필요한 부분을 파악하는 것이 어려울 수 있습니다. 그것은 당신의 수학입니까, 아니면 수학을 수행하기 위해 다른 데이터 조각에 액세스하는 방식입니까? for 루프인가요? if 진술?

코드가 일부 임시 기능으로 실행될 때 수동으로 틱을 계산하여 측정 범위를 좁힐 수 있습니다. 두 함수는 Time 클래스 개체의 일부입니다. get_ticks_msec 및 `get_ticks_usec`입니다. 첫 번째 측정 단위는 밀리초(초당 1,000)이고, 두 번째 측정 단위는 마이크로초(초당 1,000,000)입니다.

둘 중 하나는 해당 시간 프레임에서 게임 엔진이 시작된 이후의 시간을 반환합니다.

마이크로초 단위의 시작 및 끝 수로 코드 조각을 래핑하는 경우 둘 사이의 차이는 해당 코드 조각을 실행하는 데 걸린 시간입니다.

# Measuring the time it takes for worker_function() to run
var start = Time.get_ticks_usec()
worker_function()
var end = Time.get_ticks_usec()
var worker_time = (end-start)/1000000.0

# Measuring the time spent running a calculation over each element of an array
start = Time.get_ticks_usec()
for calc in calculations:
    result = pow(2, calc.power) * calc.product
end = Time.get_ticks_usec()
var loop_time = (end-start)/1000000.0

print("Worker time: %s\nLoop time: %s" % [worker_time, loop_time])

경험이 많은 프로그래머가 되면 이 기술은 덜 필요해집니다. 실행 중인 프로그램의 어떤 부분이 느린지 배우기 시작합니다. 루프와 분기가 느릴 수 있다는 것을 아는 것은 경험에서 비롯되며, 측정하고 연구를 수행하여 경험을 얻습니다.

그러나 프로파일러와 틱 기능 사이에는 최적화가 필요한 코드 부분을 찾는 데 충분한 정보가 있어야 합니다.