[WWDC24] Explore swift performance - Introduction, What is performance?

[jcrescent61]

본문 보러가기

Introduction

이번 Explore swift performance(Swift의 성능 살펴보기) 에서는 제목 그대로 Swift의 성능에 대해서 알아보자. 한 프로그래밍 언어로 많은 작업을 할때 해당 언어로 작성된 다양한 연산이 어떤 성능을 내는지 직관적으로 알 수 있어야한다.

C언어 프로그래머의 경우 그런 경우가 많다. C 언어는 기계어 코드로 리터럴 하게 번역된다.

이와 같은 로컬 변수는 스택에 할당되며

힙 할당은 호출을 하는 경우에만 이루어진다.
컴파일러가 데이터를 레지스터로 옮기거나 메모리를 최적화하는 등 작업 속도를 높이는 여러 영리한 방법이 있지만 적절한 컴파일 방식에는 기본 원리가 있다.

"리터럴하다" 특정 표현이나 언어적 요소가 문자 그대로 사용된다.

Swift는 간단하지 않다. 부분적으로는 안정성 때문이다. C에서는 깔끔한 기계어 코드를 얻을 수 있지만 코드를 잘못 작성하면 메모리가 완전히 난잡해진다. 대신 Swift는 C에서 제공하지 않는 다양한 추상화 기능과 클로저, 제네릭 등을 지원한다. 이러한 추상화 기능은 간단하게 구현되어 있지 않으며, 명시적으로 malloc을 호출하듯이 명확한 비용을 알 수 없다. 그렇다고 해서 코드의 실제 실행 방식에 대한 비슷한 직관을 기를 수 없는 것은 아니다. 성능과 관련된 작업에서는 이러한 직관이 매우 중요한데, 이번 아티클에서는 Swift의 로우 레벨 성능에 대해 살펴보자. 먼저 성능이란 무엇을 의미하는지 살펴보고 로우 레벨 성능에 대해 생각할 때 고려해야 하는 여러 기본 원칙을 살펴보자. 끝으로 Swift의 주요 기능이 어떻게 구현되어 있는지 세부적으로 살펴보며 그러한 기능이 성능에는 어떤 영향을 주는지 알아보자.

What is performance?

상당히 심오한 질문이다. 만약 어떤 도구가 있어서 프로그램을 그 도구에 집어넣으면 하나의 숫자가 출력되고 그 숫자로 프로그램의 성능을 모두 알 수 있다면 얼마나 좋을까? 이를테면 Safari의 성능 점수가 9.2라고 출력되는 것 처럼. 아쉽지만 그렇게 할 수는 없다. 성능은 다차원적이고 상황에 따라 달라지기 때문이다.

우리는 보통 거시적인 차원에서 성능에 대해 다룬다. 데몬이 너무 많은 자원을 사용하고 있거나 UI를 클릭할 때 지나치게 느리게 반응하거나 앱이 계속 중단되는 경우처럼 이러한 문제를 조사할 때는 보통 하향식으로 접근한다.

instruments와 같은 도구로 측정해보면 어디를 살펴봐야 할지 확인할 수 있다. 대부분의 이러한 문제는 알고리즘을 개선하여 해결한다. 코드의 로우 레벨 성능까지 굳이 살펴보는 일은 없을 것이다.

하지만 가끔은 로우 레벨 성능까지 살펴봐야 한다. 어떤 경우에는 조사의 범위를 실행 추적의 어느 한 부분까지 좁힐 수 있었지만 알고리즘 수준에서 더 이상 개선할 부분이 없을 수도 있을 것이다. 그냥 느리게 실행되는 것이다. 더 나아가려면 코드가 실제로 어떻게 실행되는지 이해해야 하고 그렇게 하려면 상향식 접근 방식이 필요하다.

로우 레벨 성능은 대체로 다음 4가지 사항에 크게 영향을 받는다.

1. Function calls: 효율적으로 최적화되지 않은 수 많은 호출에 영향을 받는다.
2. Memory layout: 데이터를 표현하는 방식에 많은 시간 또는 메모리를 소비한다.
3. Memory allocation: 메모리를 할당하는 데 너무 많은 시간을 소비하며
4. Value copying: 불필요하게 값을 복사하고 파괴하며 많은 시간을 허비한다.

Swift 기능의 대부분은 이러한 비용 중 하나 이상에 영향을 준다.

모든 사항을 살펴보려하는데 마지막으로 고려할 사항(다섯 번째)을 하나 추가하겠다. Swift에는 강력한 옵티마이저가 있다. 몇 가지 성능 문제는 발생할 일이 없는데 컴파일러가 효과적으로 제거해 주기 때문이다.

최적화에는 한계가 있다. 코드를 작성하는 방식은 옵티마이저의 최적화 성능의 큰 영향을 줄 수 있다. 이번 주제를 다루면서 최적화 가능성에 대해서도 다룰 예정이다. 성능과 관련해 프로그래밍에서 중요한 부분이기 때문이다.

옵티마이저에 의존하는 것이 불편한 사람들을 위해 한 가지 제안을 하자면 프로젝트에서 성능이 중요하다면 정기적인 모니터링이 필요하다. 하향식으로 조사하다가 문제가 될 만한 부분을 발견하면 측정할 수 있는 방법을 찾고 그러한 측정을 자동화하여 개발 프로세스에 포함하면 된다. 그런 식으로 진행하면 퇴행의 원인을 제대로 식별하여 어떤 식으로든 옵티마이저를 혼란스럽게 만든 것이 문제인지 2차 복잡도 알고리즘을 실수로 추가한 것이 원인인지 알 수 있다. 그러면 이제 옵티마이저가 원하는 대로 잘 작동하는지 파악할 수 있다.

다음 아티클 링크