ABOUT ME

-

Today
-
Yesterday
-
Total
-
  • 오브젝트 풀링
    이것저것 2018. 6. 6. 14:16

    컴퓨터 하드웨어 구성과 운영체제에 대해 공부를 했다면 프로그램의 힙 영역 메모리의 할당과 소멸은 큰 부담이 되는것을 알것이다.

    결론적으로 말하자면 CPU 캐시 메모리와 주 메모리 간의 속도차이가 상당 하기 때문이다. 그렇기 때문에 가급적이면 메모리에 접근하는 일을 줄이는 것이 어떤 개발 환경을 막론하고 간에 퍼포먼스 향상에 큰 도움이 된다.

    일반적으로 객체의 생성과 소멸이 빈번하지 않은 객체의 경우 큰 문제가 되지 않는다. 하지만 빈번하게 생성과 소멸이 이루어지는 객체의 경우, 어떻게 하면 퍼포먼스를 높힐 수 있을까? 이미 너무나도 잘 알려진 방법이지만 메모리에 올라간 객체들의 소멸시기에 소멸시키지 않고 재활용하는 오브젝트 풀링을 하면 된다. 나는 최근 구현하고 있는 게임에서 몹시 빈번하게 생성과 소멸이 이루어지는 객체들을 효율적으로 관리해야 하는 문제를 만났다.

    특정 객체의 한해 풀링을 해주는 스크립트를 어렵지 않게 작성할 수 있었다. 구조는 이렇다.

    특정 객체(Prefab)에 대한 오브젝트 풀을 만들고 생성 객체에게 관리자 객체(오브젝트 풀)의 정보를 전달하여 특정 객체의 생성을 위임(delegation) 한다.

    하지만 얼마지나지 않아 객체의 종류에 대해 종속되지 않고 일반화 된 오브젝트 풀을 구현할 수 없을까라는 생각이 들었다.

    이것에 대한 가장 큰 문제는 각각의 다른 특성들을 지닌 객체들을 어떻게 하나의 풀로 관리할 수 있을것인가 였다.

    다만 정말 유용하게도 유니티처럼 모든 객체들이 컴포넌트들의 집합으로 구성되는 특성을 가지는 구조의 경우 생성과 접근이 굉장히 용이하다.

    유니티의 경우 모든 오브젝트들은 GameObject를 상속받는다는 법칙이 있기 때문이다.

    결과적으로 내가 바꾼 오브젝트 풀은 초기에 에디터를 통해 Prefab들의 정보를 설정할때 문자열이라는 고유의 키값을 통해 오브젝트들을 구분하고 관리한다.

    프리팹을 통해 이미 구조화되어 있는 객체들을 키값(문자열)을 통해 일관되게(GameObject) 받아서 각 객체별로 가지고 있는 다형성(각각의 컴포넌트들)에 접근하여 원하는 처리를 하면 되는것이었다. (생성 객체의 경우 원활한 사용을 위해서는 이미 특정 객체의 정보를 알고 있어야하므로 여기서 생기는 종속성을 불가피하다고 생각한다. 혹시 이 조차도 제거할 수 있는 방법을 안다면 알려주시면 감사하겠습니다..(인터페이스를 활용한 방법 빼고))

    유니티의 경우 생성 팩토리를 통한 생성 추상화 같은건 필요성을 느끼지 못했다. 그 이유는 유니티는 Prefab이라는 좋은 오브젝트 아카이빙?을 통해서 각각 프리팹에 대해 구체적(Concrete)으로 번잡한 소스코드 타이핑 없이 파일을 통해 객체들을 정의, 관리할 수 있기 때문이다. 물론 그 종류가 너무 다양하고 객체의 특성이 미래에 확장 가능성이 충분하다면 팩토리를 통해 프리팹을 스크립트화 생성하는것도 좋은 접근법일듯 하다... 하지만 당장 내가 처한 상황에서는 그렇게 다양하지 않았고 컴포넌트에 대한 접근을 인터페이스화 하면 종속성을 제거할 수 있겠으나 현재로서는 컴포넌트 구성이라는 좋은 특성을 두고 굳이 그럴 수고가 있는가는 생각이 든다.


    요약하면 내가 변경한 오브젝트 풀의 장점은 두가지다

    1. 하나는 객체를 생성해야 하는 객체들은 오브젝트 풀을 통해 실제로 할당이 일어났는지 일어나지 않았는지 확인할 필요가 없다. 그 책임은 오브젝트를 관리하는 풀에서 전담하기 때문이다. (이건 그냥 풀이 가지고 있는 장점중 하나인듯...), (그리고 퍼포먼스가 좋아지는건 기본적인 효과)

    2. 런타임 중에 객체의 생성을 판단하는 생성 객체들은 자신이 생성하려는 객체가 무엇인지 알아야하고 그 접근을 위해서는 그 객체들을 관리하는 매니저 객체(오브젝트 풀)에 대해 알아야하는 한마디로 풀과 생성 객체간의 종속성이 생길 수 밖에 없다. 이 종속성을 효과적으로 해결할 수 있는 방법이 과연 있기나 한지 의문이 드는데 혹시 그 방법을 알고 있는 분은 연락주시면 감사 하겠습니다. 여튼, 생성 객체는 매니저 객체에 대해서 알아야하는데 매니저를 하나의 특수 객체(생성과 관리만을 담당하는)로 설정한다면 관리와 최소한의 종속으로 인한 관리가 편해진다.


    사실 소스코드로 보자면 10줄도 안되는 정말 보잘것 없는 코드의 수정에 불과하다... 하지만 이 글을 쓰는 이유는 그런 사소한 변경일지라도 그에 대한 근거와 타당성을 고려 할 수 있는, 구체적인 장,단점을 생각하는 습관을 기르기 위해서이다.

    '이것저것' 카테고리의 다른 글

    우리가 취미를 가져야 하는 이유  (0) 2021.04.01
Designed by Tistory.