[📚정보] 좃뉴비도 쉽게 적용할 수 있는 가비지 최적화 (유니티 / C#)

[익명(220.70)]

갤 쭉 보니까 실력 있는 사람도 많지만 입문하는 사람들도 많은 것 같더라고

그래서 내일 출근도 안 하겠다, 뉴비들에게 도음 될만한 글 하나 싸고 감.

나는 좃소 프로그래머고 프로젝트 전반 최적화, 관리 업무 담당하고 있음.

솔직히 객관적으로 누굴 가르칠 정도로 잘 한다고는 못하겠는데 

안 짤리고 붙어 있는거 보면 최소컷은 된다는 거겠지

쨌든 본론으로 들어가면,

최적화는 기본적으로 코드 로직부터 해서 리소스(사운드, 텍스쳐, 모델링 등등)까지 굉장히 광범위하게 적용되어야 함.

또 성능과 퀄리티를 적절히 타협하는 상황이나, 성능이 떨어지더라도 감수하고 넘어가야 할 부분을 판단하는 것 등등.. 

단순히 지식 뿐만 아니라 경험이 필요한 경우가 많음. 또 이런 것들을 글 하나로 다 정리할 수 있는 것도 아니기도 하고..

기본적이면서도 누구나 쉽게 구조 변경 없이 진행 중인 프로젝트에도 바로 적용할 수 있고, 효과를 볼 수 있는 내용을 써볼까 함.

이 글에서 설명할 내용은 힙과 스택, 가비지 컬렉션에 대한 최소한의 이해를 바탕으로 한 인사이트 확장임.

사실 굉장히 기본적인 내용인데, 신입 수준 프로그래머와 일할 때 이러한 내용을 아예 모르는 경우도 허다함.

쉬운 내용이긴 하지만 C#에 대한 최소한의 지식은 갖고 있어야 알아 먹을 수 있을 것임.

유니티를 굴리다 보면 가비지를 최소화 해야한다, 가비지가 프레임 드랍의 원흉이다 이런 말들을 많이 들을 수 있음.

자연히 그럼 어떻게 해야 이러한 가비지를 최소화 할 수 있는데? 라는 의문을 갖게 됨.

그 답을 얻기 위해선 일단 가비지가 무엇인지, 언제 생기는 것인지 알 필요가 있음.

기본적으로 메모리의 구조에 대해 알고 있으면 좋음.

OS 관련해서 공부했다면 본 기억이 있을 것임. 자세한 내용은 알아서들 공부하고

이 글의 내용을 이해하고 써먹기 위해서는 그냥 힙, 스택 두 개만 기억해두면 됨. 

당연히 나중에 따로 공부해서 다 알고 있으면 훨씬 좋다.

가비지는 힙 영역에 할당된 메모리 중 레퍼런스(참조)를 잃은 메모리들을 말함.

즉 메모리 공간이 할당되었지만 레퍼런스를 모두 잃었기 때문에, 더 이상 그 메모리 공간을 사용할 수 없는 상태가 된 것임.

C#에서는 이렇게 사용할 수 없게 된 메모리 공간을 가비지라고 칭하고, 가비지 컬렉션이라는 작업을 수행해서 사용하지 않는 메모리 공간을 정리함.

이 과정에서 꽤 많은 비용이 들기 때문에 프레임 드랍이 발생하게 되는 것임.

다시 정리하면 힙에 할당된 애들 중 못쓰는 애들을 가비지라 함.

즉, 힙에 할당되지 않는 애들은 가비지가 아니고, 가비지 컬렉션의 대상이 아님.

따라서 힙에 할당되는 애들만 신경 쓰면 되고, 얘네가 레퍼런스를 잃지만 않으면 가비지는 절대 생기지 않는다는 것임.

이 정도만 알고 있어도 가비지로 인한 성능 저하를 크게 줄일 수 있음.

사실 제대로 설명하려면 길고 복잡해지지만 그냥 딱 이거만 알면 됨.

'class를 생성하면 힙에 할당 된다.'

힙이 뭔지, 어떻게 굴러가는지 사실 당장 알 필요는 없다.

이것만 알고 가자. class는 어디에서 생성하든 힙에다 때려 박고 시작한다.

다음 코드를 보자.

void Update()
{
var tList = new List<int>();

tList.AddRange(otherList);

foreach(var a in tList)
{
//~~
}
}

위 코드가 신입들이 많이 실수하는 대표 예시임.

저 Update가 for-loop가 될 수도 있고 프레임마다 호출하는 어떤 다른 method가 될 수도 있고..

앞서 설명했듯 class는 힙에 할당된다.

List는 C#에서 제공하는 자료구조이자 여러 인터페이스를 상속하고 있는 class이고 

변수 tList의 수명은 선언 이후 Update 루프 한 번이 끝날 때까지임.

즉 저 Update 루프가 끝나면 tList는 수명이 끝나게 되고 List의 레퍼런스가 해제된다.

리스트가 할당 받은 힙 메모리 공간을 가리키는 변수가 사라지게 되고 자연스럽게 가비지가 된다.

문제는 Update는 유니티에서 프레임마다 호출하는 event method라는 것이고, 위 코드는 프레임마다 가비지를 쏟아내는 코드라는 말이 된다.

그럼 어떻게 고칠 수 있을까?

private List<int> tList = new List<int>();
void Update()
{
tList.Clear();
tList.AddRange(otherList);

foreach(var a in tList)
{
//~~
}
}

이렇게만 고쳐도 리스트의 레퍼런스가 해제되면서 가비지가 생길 일은 없어진다.

Update에서 class를 생성하고 있지도 않고 변수의 수명 또한 Update 루프와는 무관하기 때문임.

캐싱에 대해선 두 번째 예시에서 간단히 설명하겠지만 캐싱의 한 예시라고 할 수 있다.

예시가 굉장히 초보적이고 직관적이어서 쉽게 파악할 수 있을 것임.

추가로, 이 예시만 보고 캐싱 하고, Clear를 사용하면 안전하다 생각하면 안된다.

만약 List의 멤버가 class고, 멤버들의 레퍼런스를 가지고 있는 객체가 해당 리스트가 유일하다면 Clear시 대량의 가비지를 쏟아내게 될 것임.

물론 위 코드에선 AddRange를 쓰고 있는 것으로 보아 다른 자료구조에 class가 있어서 항상 안전하긴 하지만, 다른 경우에는 조심해야 한다.

두 번째 예시임

private IEnumerator CoTest()
{
yield return new WaitForSeconds(0.5f);
}

위 코드에서도 가비지가 발생한다.

아래에서 볼 수 있듯, WaitForSeconds가 class이기 때문임.

public sealed class WaitForSeconds : YieldInstruction
{
internal float m_Seconds;

/// <summary>
/// <para>Suspends the coroutine execution for the given amount of seconds using scaled time.</para>
/// </summary>
/// <param name="seconds">Delay execution by the amount of time in seconds.</param>
public WaitForSeconds(float seconds) => this.m_Seconds = seconds;
}

객체를 생성하지만 가리키는 변수가 없고

코루틴에서 WaitForSeconds의 역할이 끝나면 바로 가비지로 잡혀서 GC의 대상이 되는 것.

이를 방지하기 위해 '캐싱'이라는 수단을 많이 사용한다.

클래스 내부 혹은 전역으로 변수를 만들어 놓고 거기다가 객체를 생성하는거지.

그렇게 하면 클래스가 수명이 다하거나 전역 변수라면 프로그램이 종료될 때 까지 레퍼런스가 잡혀있기 때문에 가비지가 되지 않는다.

private readonly WaitForSeconds wait0Dot5 = new WaitForSeconds(0.5f);

private IEnumerator CoTest()
{
yield return wait0Dot5;
}

간단하게는 이런 식으로 사용할 수 있다.

코루틴에서 단순히 일정 시간 멈추는 기능으로 사용되다 보니, 

class임을 인지하지 못하고 놓칠 수 있는 부분이고 캐싱을 간단하게 설명하기 위해 가져온 예시임.

세번째는 StartCoroutine이다.

StartCoroutine에도 가비지가 발생한다.

/// <summary>
/// <para>Starts a Coroutine.</para>
/// </summary>
/// <param name="routine"></param>
public Coroutine StartCoroutine(IEnumerator routine)
{
if (routine == null)
throw new NullReferenceException("routine is null");
if (!MonoBehaviour.IsObjectMonoBehaviour((Object) this))
throw new ArgumentException("Coroutines can only be stopped on a MonoBehaviour");
return this.StartCoroutineManaged2(routine);
}

위에서 볼 수 있듯 StartCoroutine은 Coroutine이라는 class를 뱉어낸다.

당연히 리턴된 Coroutine을 변수로 참조하고 있지 않다면 가비지로 잡히게 될 것임.

근데 사실 StartCoroutine같은 경우는 그냥 가비지를 감수하고 쓰는 경우가 훨씬 많다.

아무 생각 없이 사용하는 함수들이(특히 외부 플러그인 또는 유니티 api) 힙에 할당되는 애들을 생성해서 뱉어내는 경우도 있다는 것을 설명하고 싶었음.

몇 가지 예시를 들었는데 충분히 잘 설명이 됐는지 모르겠네.

여기에 추가로 가비지를 생성하는 코드들이 자주 실행되지 않도록 하는 것 정도를 기억하면 될 것 같다.

예시들 외에도 string 이나 내부적으로 임시 객체를 생성하는 method들 등등.. 신경 쓸게 많긴 한데,

결국 '힙에 할당된 메모리에 대한 레퍼런스가 없어졌기 때문에 가비지가 발생한다.'로 모든 상황을 설명할 수 있다.

즉 가비지를 관리한다는 것은 모든 객체(class)를 프로그래머의 통제(변수)하에 두는 행위인데

그 시작이 바로 '가비지는 힙에 할당된 애들 중에 미아가 된 애들을 말한다.', 'class를 생성하면 힙에 할당 된다.'를 머리통에 때려 박아 놓는 것임.

코드를 치다가 객체를 생성하는데 'class를 생성하면 힙에 할당 된다.'는 사실이 머리통에 있다면

자연스럽게 함수가 얼마나 호출되는지, 객체를 여기서 생성할 필요가 있는지, 캐싱을 하는 게 더 나은지, 그냥 가비지를 감수하는 게 나은지 등등을 고려하게 될 것임.

물론 여러 상황을 고려하게 되었다고 해서 정답을 내릴 수 있는 건 아니다. 애초에 정답이 없기도 하고. 

그건 경험이 해결해 줄 일임.

사실 어느 언어를 하든, 어느 엔진을 쓰든 기본 중에 기본인 내용인데 유니티 자체가 워낙 쉽다 보니 그냥 무작정 들이박는 경우도 많고

C#이 managed memory라 프로그래머가 그냥 힙을 쓰레기통처럼 써도 알아서 정리해줘서 모르고 넘어가는 사람들이 많은 것 같기도 함.

가비지 최적화 전략은 이 글에 작성된 내용이 큰 부분을 차지하긴 하지만, 전부는 아님

경우에 따라 가비지를 감수하고 프로그래머 의도 하에 GC를 발생 시켜서 중요한 시점에 프레임 드랍을 막을 수도 있고

메모리를 아끼기 위해 가비지를 그냥 감수하는 경우도 있다.

이런 건 뭐 경험이 쌓이면 알아서 판단하게 될 내용들이라 안 썼음.

좃도 없는데 쓸데없이 길게 쓴 것 같네. 열심히 개발하도록 하자

*전공 지식이 필요한 내용은 최대한 빼고 쓰느라 좀 어긋나거나 일반적으로 얘기하는 것과 다른 내용이 있을 수 있음.

*추가로 글에 쓰인 용어가 일반적으로 사용되는 말이 아닐 수도 있다. 근데 대충 이렇게 말하면 다 알아듣더라고

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(220.70)]

메모리 사용량이 늘어나는 건 맞고 가비지를 적게 유지한다 -> GC 빈도 수가 줄어든다 -> GC 비용 감소

[익명(220.70)]

쓰고있는 메모리가 많으면 scan time이 늘어나는 건 맞는데 그게 제대로 잘 쓰고 있는 메모리라면 당연히 감수해야 할 부분이고 쓸데없이 가비지 안 만들겠다고 레퍼런스를 쥐고 있는 상황이면 님 말이 맞음

[익명(220.70)]

.net gc랑 유니티 gc랑 약간 다른 점도 있긴 한데 둘 다 generation 기반으로 관리하는 것으로 알고 있음. 가비지 스캔에서 살아남은 애들은 다음 스캔에서 뺀다든지 하는 방식으로 동작함. 그러다보니 사실 인디 규모에서는 scan 타임으로 문제를 겪을 일은 거의 없을 것이라고 생각함

[익명(119.194)]

찐 뉴비로서 이건 개추박고 가야한다. 감솨합니다. 대협

[익명(39.112)]

[해당 댓글은 삭제되었습니다.]

해당 댓글은 삭제되었습니다.

[익명(220.70)]

관점 차이임 가비지를 만들지 않으려면 레퍼런스를 잡고 있어야하고, 그러면 사용하지 않을 때도 메모리를 점유하게 되겠지. 안쓰는 동안에는 이걸 '낭비'라고 생각할 수 있음. 가비지는 정리되기 전까지는 메모리를 먹긴 하지만, GC가 수행된 이후에는 빈 메모리가 되기 때문에 여유 메모리가 생기는 것임.

[익명(220.70)]

좀 더 타이트하게 관리하려면 Dispose 패턴을 사용하는데, 난 그렇게 까진 거의 안하는 편임

[111(1.234)]

제발이런거 신경쓰지말고 겜이나만들어 병신들아

[익명(1.250)]

니가 뭔데 좆밥아ㅋㅋㅋ - dc App

[익명(1.234)]

팩트: 첫번째 사진은 c# 자동으로 스택으로 할당함