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...

애니메이션

소개

이상적인 세계에서는 컴퓨터가 무한한 속도로 실행됩니다. 우리가 성취할 수 있는 유일한 한계는 우리의 상상력일 것입니다. 그러나 현실 세계에서는 가장 빠른 컴퓨터도 무릎꿇게 만드는 소프트웨어를 만드는 것이 너무 쉽습니다.

따라서 게임 및 기타 소프트웨어를 디자인하는 것은 우리가 원하는 것과 좋은 성능을 유지하면서 현실적으로 달성할 수 있는 것 사이의 절충안입니다.

최상의 결과를 얻으려면 두 가지 접근 방식이 있습니다.

  • 더 빠르게 작업하세요.

  • 더 스마트하게 일하세요.

그리고 바람직하게는 두 가지를 혼합하여 사용하는 것이 좋습니다.

노드와 리소스

더 현명하게 일하는 것의 일부는 게임에서 플레이어가 실제보다 훨씬 더 복잡하고 상호 작용하며 그래픽적으로 흥미로운 세계에 있다고 믿게 만들 수 있다는 것을 인식하는 것입니다. 좋은 프로그래머는 마술사이며, 새로운 것을 발명하려고 노력하면서 기술을 배우려고 노력해야 합니다.

느림의 본질

외부 관찰자가 보기에 성능 문제는 종종 하나로 묶이게 됩니다. 그러나 실제로는 여러 종류의 성능 문제가 있습니다.

  • 프레임마다 발생하는 느린 프로세스로 인해 지속적으로 낮은 프레임 속도가 발생합니다.

  • 속도 저하의 "급증"을 유발하여 중단으로 이어지는 간헐적인 프로세스입니다.

  • 예를 들어 레벨을 로드할 때와 같이 일반적인 게임플레이 외부에서 발생하는 느린 프로세스입니다.

이들 각각은 사용자를 짜증나게 하지만 방식은 다릅니다.

성능

아마도 최적화를 위한 가장 중요한 도구는 성능을 측정하는 능력, 즉 병목 현상이 있는 위치를 식별하고 속도를 높이려는 시도의 성공 여부를 측정하는 능력일 것입니다.

원하는 용도에 따라 리지드 바디의 움직임을 제어하는 몇 가지 방법이 있습니다.

다양한 영역의 상대적 성능은 하드웨어에 따라 달라질 수 있다는 점을 명심하세요. 둘 이상의 장치에서 타이밍을 측정하는 것이 좋은 경우가 많습니다. 특히 휴대기기를 타겟팅하는 경우 더욱 그렇습니다.

제한 사항

CPU 프로파일러는 성능 측정을 위해 자주 사용되는 방법입니다. 그러나 그들은 항상 전체 이야기를 말하지는 않습니다.

  • 병목 현상은 종종 CPU에서 제공한 명령의 "결과"로 GPU에서 발생합니다.

  • Godot에서 사용된 명령(예: 동적 메모리 할당)의 "결과"로 운영 체제 프로세스(Godot 외부)에서 스파이크가 발생할 수 있습니다.

  • 필요한 초기 설정으로 인해 휴대폰과 같은 특정 장치를 프로파일링하지 못할 수도 있습니다.

  • 액세스할 수 없는 하드웨어에서 발생하는 성능 문제를 해결해야 할 수도 있습니다.

이러한 제한으로 인해 병목 현상이 있는 위치를 찾기 위해 탐색 작업을 수행해야 하는 경우가 많습니다.

조사 작업

탐정 작업은 성능 측면과 버그 수정 측면 모두에서 개발자에게 중요한 기술입니다. 여기에는 가설 테스트 및 이진 검색이 포함될 수 있습니다.

시험

예를 들어, 스프라이트가 게임 속도를 늦추고 있다고 생각한다고 가정해 보겠습니다. 다음을 통해 이 가설을 테스트할 수 있습니다.

  • 더 많은 스프라이트를 추가하거나 일부를 제거할 때 성능을 측정합니다.

이는 추가 가설로 이어질 수 있습니다. 스프라이트의 크기가 성능 저하를 결정합니까?

  • 모든 것을 동일하게 유지하면서 스프라이트 크기를 변경하고 성능을 측정하여 이를 테스트할 수 있습니다.

프로파일러

프로파일러를 사용하면 프로그램을 실행하는 동안 프로그램 시간을 측정할 수 있습니다. 그런 다음 프로파일러는 다양한 기능과 영역에서 소요된 시간의 비율과 기능이 호출된 빈도를 알려주는 결과를 제공합니다.

이는 병목 현상을 식별하고 개선 결과를 측정하는 데 매우 유용할 수 있습니다. 때로는 성능을 향상시키려는 시도가 역효과를 낳고 성능이 저하될 수 있습니다. 항상 프로파일링과 타이밍을 활용하여 노력을 안내하세요.

Godot의 내장 프로파일러 사용에 대한 자세한 정보는 프로파일러를 참조하세요.

원칙

도널드 커누스는 말했습니다:

프로그래머는 프로그램의 중요하지 않은 부분의 속도에 대해 생각하거나 걱정하는 데 엄청난 시간을 낭비하며 이러한 효율성을 위한 시도는 실제로 디버깅 및 유지 관리를 고려할 때 매우 부정적인 영향을 미칩니다. 우리는 97% of 정도의 작은 효율성을 잊어야 합니다. 조기 최적화는 모든 악의 근원입니다. 하지만 우리는 그 중요한 3%에 대한 기회를 놓쳐서는 안 됩니다.

메시지는 매우 중요합니다.

  • 개발자 시간은 제한되어 있습니다. 프로그램의 모든 측면을 맹목적으로 속도를 높이려고 하기보다는 정말로 중요한 측면에 노력을 집중해야 합니다.

  • 최적화를 위한 노력은 종종 최적화되지 않은 코드보다 읽고 디버그하기 어려운 코드로 끝나게 됩니다. 이를 실제로 이익이 될 영역으로 제한하는 것이 우리의 이익입니다.

특정 코드 부분을 최적화할 수 있다고 해서 이것이 반드시 해야 한다는 의미는 아닙니다. 최적화할 시기와 하지 않을 시기를 아는 것은 개발할 수 있는 훌륭한 기술입니다.

인용문의 오해를 불러일으키는 측면 중 하나는 사람들이 "성급한 최적화는 모든 악의 근원이다"*라는 하위 인용문에 집중하는 경향이 있다는 것입니다. *성급한 최적화는 (정의상) 바람직하지 않지만, 고성능 소프트웨어는 고성능 설계의 결과입니다.

성능이 뛰어난 디자인

사람들이 필요할 때까지 최적화를 무시하도록 장려하는 데 따른 위험은 성능을 고려해야 하는 가장 중요한 시기가 키보드를 누르기 전인 설계 단계라는 점을 편리하게 무시한다는 것입니다. 프로그램의 설계나 알고리즘이 비효율적이라면 나중에 세부 사항을 아무리 다듬어도 프로그램이 빠르게 실행되지 않습니다. 더 빠르게 실행될 수 있지만 성능을 위해 설계된 프로그램만큼 빠르게 실행되지는 않습니다.

이는 일반 프로그래밍보다 게임이나 그래픽 프로그래밍에서 훨씬 더 중요한 경향이 있습니다. 낮은 수준의 최적화가 없더라도 성능이 뛰어난 디자인은 낮은 수준의 최적화가 적용된 평범한 디자인보다 몇 배 더 빠르게 실행되는 경우가 많습니다.

증가하는 업데이트/패치

물론 실제로 사전 지식이 없으면 처음부터 최고의 디자인이 나올 가능성은 거의 없습니다. 대신, 만족스러운 해결책을 찾을 때까지 특정 코드 영역에 대해 일련의 버전을 만들어 각각 문제에 대해 서로 다른 접근 방식을 취하는 경우가 많습니다. 전체 디자인을 마무리할 때까지 이 단계에서 세부 사항에 너무 많은 시간을 소비하지 않는 것이 중요합니다. 그렇지 않으면 작업의 대부분이 폐기될 것입니다.

성능 설계에 대한 일반적인 지침을 제공하는 것은 문제에 따라 크게 달라지기 때문에 어렵습니다. 그러나 CPU 측면에서 언급할 가치가 있는 한 가지 점은 최신 CPU는 거의 항상 메모리 대역폭에 의해 제한된다는 것입니다. 이로 인해 메모리 내에서 점프하는 대신 데이터의 캐시 지역성 및 선형 액세스를 위한 데이터 구조 및 알고리즘을 설계하는 데이터 지향 설계가 다시 부활하게 되었습니다.

애니메이션

우리가 합리적인 설계를 갖고 있고 Knuth로부터 교훈을 얻었다고 가정하고 최적화의 첫 번째 단계는 가장 큰 병목 현상, 즉 가장 느린 기능, 쉽게 달릴 수 없는 열매를 식별하는 것입니다.

가장 느린 영역의 속도를 성공적으로 개선하면 더 이상 병목 현상이 발생하지 않을 수 있습니다. 따라서 우리는 다시 테스트/프로파일링하고 집중해야 할 다음 병목 현상을 찾아야 합니다.

따라서 프로세스는 다음과 같습니다.

  1. 프로필/병목 현상을 식별합니다.

  2. 병목 현상을 최적화합니다.

  3. 반환

병목 현상 최적화

일부 프로파일러는 함수의 어느 부분(데이터 액세스, 계산)이 속도를 저하시키는지 알려 주기도 합니다.

디자인과 마찬가지로 먼저 알고리즘과 데이터 구조가 최상의 상태인지 확인하는 데 노력을 집중해야 합니다. 데이터 액세스는 로컬이어야 하며(CPU 캐시를 최대한 활용하려면) 컴팩트한 데이터 저장소를 사용하는 것이 더 나을 수도 있습니다(역시 항상 테스트 결과를 프로파일링함). 많은 양의 계산을 미리 계산하는 경우가 많습니다. 이는 레벨을 로드할 때 계산을 수행하거나, 미리 계산된 데이터가 포함된 파일을 로드하거나, 복잡한 계산 결과를 스크립트 상수에 저장하고 해당 값을 읽어서 수행할 수 있습니다.

알고리즘과 데이터가 좋으면 루틴에 작은 변화를 주어 성능을 향상시킬 수 있는 경우가 많습니다. 예를 들어 일부 계산을 루프 외부로 이동하거나 중첩된 for 루프를 중첩되지 않은 루프로 변환할 수 있습니다. (2D 배열의 너비나 높이를 미리 알고 있는 경우 가능합니다.)

매번 변경한 후에는 항상 타이밍/병목 현상을 다시 테스트하세요. 일부 변경 사항은 속도를 증가시키고 일부 변경 사항은 부정적인 영향을 미칠 수 있습니다. 때로는 작은 긍정적인 효과가 더 복잡한 코드의 단점보다 더 클 수 있으므로 해당 최적화를 생략하도록 선택할 수도 있습니다.

부록

병목 현상 수학

*"체인은 가장 약한 링크만큼 강하다"*라는 속담은 성능 최적화에 직접적으로 적용됩니다. 프로젝트가 A 함수에서 90% of의 시간을 소비하는 경우 ``A``를 최적화하면 성능에 막대한 영향을 미칠 수 있습니다.

A: 9 ms
Everything else: 1 ms
Total frame time: 10 ms

A: 1 ms
Everything else: 1ms
Total frame time: 2 ms

이 예에서 이 병목 현상 ``A``를 9배 개선하면 전체 프레임 시간이 5배 감소하고 초당 프레임 수는 5배 증가합니다.

그러나 다른 작업이 느리게 실행되고 프로젝트에 병목 현상이 발생하는 경우 동일한 개선으로 인해 극적인 이점이 덜해질 수 있습니다.

A: 9 ms
Everything else: 50 ms
Total frame time: 59 ms

A: 1 ms
Everything else: 50 ms
Total frame time: 51 ms

이 예에서는 A 기능을 크게 최적화했지만 프레임 속도 측면에서 실제 이득은 매우 작습니다.

게임에서는 CPU와 GPU가 서로 독립적으로 실행되기 때문에 상황이 더욱 복잡해집니다. 총 프레임 시간은 둘 중 더 느린 시간에 따라 결정됩니다.

CPU: 9 ms
GPU: 50 ms
Total frame time: 50 ms

CPU: 1 ms
GPU: 50 ms
Total frame time: 50 ms

이 예에서는 CPU를 다시 대폭 최적화했지만 GPU 병목 현상으로 인해 프레임 시간이 향상되지 않았습니다.