Today I Learned - Day 66 [인스턴스는 과유불급]

일전에 GetComponent의 최적화와 관련해서 정리했던 적이 있다.

[참고 URL: https://lsu0503.tistory.com/121]

이번에는 이와 무관한 최적화 요소에 대해서 정리 해 보자.

금일은 다소 간단할 것이다.

---

C# 자체의 구조적 한계

C#은 기본적으로 쓰고 남은 클래스, 가비지의 정리를 '가비지 컬렉터'가 전담하고 있다.

그리고, 이 가비지 컬렉터는 어지간한 무겁다는 연산들에 준하거나 그보다 더 높은 연산 부하를 자랑한다.

즉, '힙 영역을 많이 사용할 수록 회적화에 적신호가 켜진다.'

 

힙 영역을 적게 사용해야 한다 = 인스턴스 수를 줄여야 한다는 것인데, 사실 이게 말 처럼 쉽지는 않다.

거기다가 가독성이나 기타 여러 사항들을 고려했을 때에는 '클래스 수를 늘리는 게 유리한' 경우도 많기도 하다.

 

그렇다면 이에 어떻게 대처해야 할까. 조금만 정리해 보자

---

모듈화

인스턴스를 적게 쓰라고 했더니, 갑자기 인스턴스를 기능 별로 분화한다는 내용을 들고왔다고 생각할 수도 있다.

다만, 이 '모듈화'는 개념이 조금 다르다. 더 확실하게는 '구조 상으로도 모듈화를 한다'고 이해하면 편하다.

 

투사체를 100개 씩 뽑아내는 공격이 있다고 가정 해 보자.

그리고 이 모든 투사체는 공격 판정을 담당하는 다수의 클래스를 들고 있다. 이는 3개로 가정한다.

그리고 그 공격 판정 클래스는 공격 효과를 담당하는 다수의 클래스를 들고 있다. 이는 5개로 가정한다.

자, 이제 총 인스턴스의 수는 어떻게 될까.

단순 계산으로도 100개의 투사체가 1900개의 인스턴스를 지니게 된다는 마법이 발생한다.

이걸 막기 위해서 모듈화를 체계적으로 해야한다는 의미다.

 

공통적인 부분 끼리는 묶어서 기반 모듈을 만들고, 그 모듈이 가지고 있던 연산은 모듈을 참조하여 들고 오기만 하면 되도록 만들어 보자. 그러면 일단 공격 판정 클래스와 공격 효과 클래스는 각각 3개, 5개로 정리가 되게 된다.

즉, 1900개의 인스터스가  생겼던 구조에서 108개의 인스턴스 만 생성 가능해도 정상 작동이 되도록 구성할 수 있다.

 

사실 가장 이상적인 경우가 위 사항이고, 저렇게 '구조 상의 모듈화'가 불가능한 경우도 있긴 하다.

그래도 위 상황을 기준으로 공격 효과 만 모듈화를 해도 인스턴스 수가 405개로 급감하는 건 매 한가지라서 이러한 구성은 항상 염두 해 두는 것이 좋다.

 

---

간단한 변수는 struct를 활용한다.

struct는 스택 영역에 저장되는 특성 상 가비지 컬랙션에 영향을 주지 않는다.

그러니, 단순 변수 저장용 같은 요소들은 클래스 보다는 구조체가 더욱 유리하다고 봐도 좋다.

 

다만, struct를 너무 많이 활용하는 것은 스택 오버플로우를 야기할 수도 있다.

적당히 쓰도록 하자.

---

금일 정리한 내용을 간추려 보면 '동시에 전개되는 인스턴스를 줄인다' 로 간단명료하다.

다만, 습관이나 숙련도 이슈로 인해서 문제가 나기가 쉬운 내용이기도 할 것이다.

그러니까 개념이라도 정리 해 놓자.

개념을 한번이라도 본 것과 몰라서 새로 구성하는 것은 차이가 클테니 말이다.