728x90

결론적으로 format이 builder보다 속도면에선 느린듯하다.

 

막대한 데이터를 가지고 반복문을 돌려서 테스트 할시에 걸리는 시간이 format 눈에 뛸정도로 오랜 시간이 걸리는것 같았다.

 

그런데 반복문이 아니라 잠깐 string을 구성할때에는 둘의 성능차이는 10%미만이라고 하니 이럴때는 사용하고 싶은걸 사용하면 될듯하고

 

반복문같이 여러번 해야할 경우에는 builder를 사용해야겠다. 빌더가 가비지 컬렉션 면에서도 더 효율적이라고 하는것 같당.

728x90
Posted by 정망스
,
728x90

enum과, struct는 값 타입이기 때문에 힙에 할당을 하지 않으므로 가비지가 생성되지 않는다.

하지만 Dictionary를 사용함으로써 enum이나 structkey로 사용할 경우 가비지가 발생되게 된다.

 

이유는 Dictionary에서는 키값이 같은지 여부를 판단할 때 System.Collections.Generic 네임스페이스 내부에 존재하는 IEqualityComparer 인터페이스를 사용하는데

 

따로 Dictionary에 비교자 객체를 집어 넣지 않는다면 비교자 객체의 기본값은 EqualityComparer<T>.Default가 되고 이 Default 프로퍼티는 T타입이 System.IEquatable<T>을 따로 구현하지 않았을 경우에 EqualityComparer<T>를 반환하는데, 얘는 Object.Equals, Object.GetHashCoe를 기본 비교 함수들로 사용한다는 것이다.

enum과 struct는 비교 함수들이 따로 구현되어 있지 않기 때문에 key로 사용하게되면

결국 저 두 함수를 통하여 enum이든 struct든 값이 object로 박싱이 되버리니 가비지가 생기게 된다는 것이다.

 

해결책은 EqualityComparer<T> 인터페이스를 상속받는 클래스를 선언해서 비교하게 하는 방법이다

이것은 struct나, enum 똑같다. 

 

public enum SomeType 
{ 
    EnumA = 1, 
    EnumB = 2, 
} 

public class SomeTypeComparer IEqualityComparer<SomeType>

    bool IEqualityComparer<SomeType>.Equals(SomeType a, SomeType b) { return a == b; } 
    int IEqualityComparer<SomeType>.GetHashCode(SomeType obj) { return (int)obj; } 
}

 

위와 같이 IEqualityComparer<T> 인터페이스를 상속받는 클래스를 선언하고

Dictionary 인스턴스를 생성할때 생성자에 인스턴스를 넣어주면 된다.

 

Dictionary<SomeTypeint> dic = new Dictionary<SomeTypeint>(new SomeTypeComparer());

728x90
Posted by 정망스
,
728x90

원문 주소 : https://unity3d.com/kr/learn/tutorials/topics/performance-optimization/profiler-window 

도입

프로파일링 툴은 우리의 게임이 어떻게 동작하는지에 대한 자세한 정보를 줍니다. 만약 우리 게임에 낮은 프레임율(framerate)이나 높은 메모리 사용과 같은 문제가 있다면, 프로파일링 툴을 통해서 무엇이 이러한 문제를 일으키는지 확인할 수 있고, 이러한 문제를 해결하는데 도움이 될 수 있습니다.

프로파일러 창(Profiler window)은 유니티에 내장되어 있는 강력한 프로파일링 툴입니다. 이 글은 프로파일러 창이 무엇이고 어떻게 사용하는지에 대한 가이드가 되어줄 것 입니다. 일단 이 글을 읽고 프로파일러 창의 레이아웃과 기능에 익숙해지고나면, 다른 종류의 성능 문제를 분석하기 위해서 프로파일러 창을 어떻게 사용하는 지를 배우게 될 것 입니다.

프로파일러 창은 우리 게임의 다른 부분들이 어떻게 돌아가고 있는지에 대한 심도있는 정보를 보여줍니다.


[그림 1 : 프로파일러 창]

프로파일러 창을 사용해서, 게임에서 메모리가 어떻게 사용되는지, 다른 작업들을 진행하는데에 얼마나 많은 CPU 시간이 소비되는지, 그리고 물리 계산이 얼마나 자주 이뤄지는지 등과 같이 게임 성능과 관련된 여러가지 면을 배울 수 있습니다. 가장 중요하게는, 이 데이터가 우리의 게임에서의 성능 문제에 대한 원인을 찾고, 그러한 문제를 해결하는 시도가 얼마나 영향을 미칠 수 있는지 측정하는데에 도움이 되도록 사용할 수 있다는 것입니다.

우리 게임에 성능 문제가 있다면, 그것을 고치려고 하기 이전에 성능 문제가 발생하는 원인을 먼저 아는 것이 필수적입니다. 다른 문제는 다른 해결책을 필요로 하기 때문이죠. 만약 우리 프로젝트가 느리게 동작하고 있고, 이 문제의 진짜 원인이 과도하게 복잡한 물리를 사용한 것이라면, 그래픽 렌더링을 개선하는 것은 전혀 도움이 되지 않습니다! 같은 이치로, 성능 문제를 해결하기 위한 시도가 얼마나 효과를 발휘했는지를 측정하는 것은 매우 중요합니다. 프로파일링 데이터를 효율적으로 사용한다는 것은 단순히 어떤 것을 변경하고나서 최고의 결과를 바라는 것이 아닌, 진짜 최적화를 할 수 있음을 의미합니다.

프로파일러 창의 레이아웃

게임의 데이터를 모으기 위해 프로파일러 창을 사용하기 전에, 먼저 프로파일러 창을 열고 레이아웃에 익숙해져봅시다.

  • 상단의 메뉴 바에서 Window > Profiler를 선택하여 프로파일러 창을 엽니다.

    [그림 2 : 프로파일러 창 레이아웃]

프로파일링 데이터가 기록되어야만 프로파일러 창에서 정보를 볼 수 있음을 꼭 기억하십시오. 우리가 처음 프로파일러 창을 열면, 실행 중인 게임으로부터 프로파일링 데이터를 기록하기 전까지는 특정 영역은 비어있습니다.

프로파일러(Profilers)

프로파일러 창의 왼쪽 열(column)에 프로파일러가 종류별로 있습니다. 각 프로파일러는 게임의 특정 부분에 대한 정보를 보여주고 있습니다. CPU 사용, GPU 사용, 렌더링, 메모리 사용, 오디오, 물리, 네트웍과 같은 프로파일러들로 구분되어 있죠.


[그림 3 : 프로파일러 열]

프로파일링 데이터가 기록되면, 프로파일러 창의 위쪽 반에 각 프로파일러의 데이터를 시간 단위로 볼 수 있습니다. 성능은 시간에 따라 달라질 수 있고, 한 프레임 이상의 성능을 보는 데에 유용합니다. 어떤 문제는 지속적으로 발생할 수도 있고, 어떤 문제는 오직 한 프레임에만 발생할 수도 있고, 또 어떤 문제는 시간이 지날수록 점점 더 좋아지거나 점점 더 나빠질 수도 있습니다.


[그림 4 : 프로파일러 데이터]

프로파일러 창의 아래쪽 반에는 현재 선택된 프로파일러의 현재 프레임에 대한 데이터에 대한 상세 정보를 볼 수 있습니다.


[그림 5 : 프로파일러 상세정보]

여기에 표시되는 데이터는 현재 어떤 프로파일러가 선택되었냐에 따라 다르게 보여집니다. 예를들어, 메모리 사용 프로파일러가 선택되었다면, 이 영역에는 어떤 에셋이 가장 많은 메모리를 사용하는지, 또 총 메모리 사용량은 얼마인지와 같은 정보들이 보여집니다. 만약 렌더링 프로파일러가 선택되었다면, 이 영역에는 렌더링되고 있는 오브젝트의 갯수나 수행되고 있는 렌더링 오퍼레이션의 갯수와 같은 통계가 보여질 것 입니다.

프로파일러는 많은 자세한 정보를 제공하지만, 우리는 프로파일링할 때마다 그러한 모든 정보가 다 필요한 것은 아닙니다; 사실, 대게는 한개나 두개 정도의 프로파일러만 사용하게 될 것 입니다. 예를들어, 느리게 돌아가는 게임이 있다면 CPU 사용 프로파일러를 보고 조사를 시작할 것 입니다.


[그림 6 : CPU 사용 프로파일러]

CPU 사용 프로파일러는 우리 게임의 어떤 부분이 가장 많은 CPU 시간을 사용하는지에 대한 개요를 보여줍니다. 우리는 그 정보를 가지고 어떤 다른 프로파일러를 살펴봐야할지 결정할 수 있죠. 예를들어, 만약 물리 함수가 실행 시 긴 시간을 사용한다면, 물리 성능에 대한 상세 정보를 얻기 위해 물리 프로파일러를 사용하겠죠.

관심없는 정보를 보지 않기 위해, 특정 프로파일러를 숨길 수도 있습니다. 각 프로파일러의 오른쪽 상단에 있는 X아이콘을 클릭해서 프로파일러를 숨길 수 있습니다.


[그림 7 : 프로파일러 숨기기]

또한 프로파일러 창의 왼쪽 상단에 있는 Add Profiler를 클릭해서 프로파일러를 추가할 수도 있습니다.


[그림 8 : 프로파일러 추가]

프로파일러를 숨기거나 추가한다고 해서 이미 모은 데이터가 사라지는 것은 아닙니다. 단순히 표시하고 있는 데이터만 보였다가 숨겼다가 하는 것이지, 실제 데이터를 삭제하는 것은 아닙니다.

컨트롤(Controls)

화면 상단 바에는 프로파일러 창의 컨트롤들이 있습니다.


[그림 9 : 상단 바 컨트롤]

이 컨트롤들을 이용해서 프로파일링을 시작하거나 정지할 수도 있고, 프로파일링 특징들을 활성화 또는 비활성화할 수도 있으며, 프로파일러가 모은 데이터 사이를 이동하는데에도 사용할 수 있습니다.

이러한 컨트롤의 전형적인 사용은, 성능 문제를 포착하기 위해 적절한 시점에 프로파일링을 시작하고 원하는 데이터를 충분히 모았다면 프로파일링을 멈추는 것입니다. 그러고나서는 타임라인 컨트롤을 이용해서 성능 문제라고 보여지는 프레임으로 이동합니다. 그러면 화면 아래쪽 반에 해당 프레임의 데이터가 표시될 것입니다.

프로파일러 창을 이용해서 게임 프로파일링 데이터 기록하기

이제 우리는 프로파일러 창에 대해서 조금 더 이해하게 되었으니, 게임 데이터를 어떻게 기록하고, 게임이 어떻게 수행되는지를 이해하기 위해서 데이터를 어떻게 읽는지 배워봅시다.

프로파일러 창에서 데이터를 기록하는데에 약간의 비용이 든다는 것을 이해하는 것은 중요합니다. 이는 모든 프로파일링 툴에서 공통적인 부분입니다; 이러한 약간의 오버헤드없이 데이터를 기록하고 표시하는 것은 불가능한 일입니다. 이는 게임이 동작하는데에 있어서 중대한 변화를 초래하지는 않지만, 프로파일러 창이 기록을 하는동안 아주 약간의 성능에 영향을 미칠 수는 있습니다.

우리의 게임을 프로파일하는 방법은 2가지가 있습니다 : 첫번째는 유니티 에디터 상에서 프로파일링하는 방법이고, 두번째는 개발 빌드(development build)를 해서 유니티 에디터 밖에서 실행시키는 방법입니다. 개발 빌드는 일반적인 빌드와는 두가지 측면에서 다릅니다 : 첫번째는 개발 빌드는 게임이 실행될 때 프로파일러 창에 연결할 수 있다는 것이고, 두번째는 개발 빌드에 디버깅을 가능하게 하는 파일들이 포함된다는 것입니다.

거의 대부분의 경우에 유니티 에디터에서보다는 개발 빌드로 프로파일링하는 것이 좋습니다. 여기에는 두가지 이유가 있습니다. 첫번째 이유는, 유니티 에디터에서보다 독립된(standalone) 개발 빌드가 성능과 메모리 사용에 대한 데이터에서 더 정확하기 때문입니다. 프로파일러 창은 유니티 에디터에서 데이터를 기록하는데, 이는 결과를 왜곡시킬 수 있습니다. 두번째 이유는, 가능하다면 타겟 기기에서 게임을 테스트하는 것이 좋기 때문입니다; 예를들어, 만약 우리 게임이 안드로이드 게임이라면 당연히 안드로이드 기기에서 테스트를 해야하는 것입니다. 특정 성능 문제는 오직 특정 하드웨어나 특정 OS에서만 발생하기 때문에, 유니티 에디터에서만 테스트를 한다면 이러한 문제를 발견하지 못할 것입니다.

그렇긴 해도, 유니티 에디터에서 프로파일링하는 것이 유용할 때도 있습니다. 아주 정확한 결과보다는 대략적인 성능 문제를 빨리 파악하기 위해서 필요한 경우가 있죠. 예를들어, 어떤 게임 오브젝트가 성능 문제를 발생시키는지를 파악하기 위해서 런타임에 대량의 게임 오브젝트를 활성화하거나 비활성화할 수 있을 것입니다. 유니티 에디터에서 이런 부분을 테스트하는 것이 여러 개의 빌드를 만드는 것보다 훨씬 빠를 것입니다. 일단 대략적으로 어떤 부분에서 문제가 발생하는지 파악된다면, 저 정확한 문제 원인을 파악하고 해결하기 위해 개발 빌드를 프로파일링할 수 있을 것입니다.

유니티 에디터에서 프로파일링하기

유니티 에디터에서 우리 게임의 데이터를 프로파일링하기 위해서는, 다음 차례를 따라야합니다.

  • 프로파일링하고 싶은 프로젝트를 유니티에서 엽니다.
  • 상단 메뉴 바의 Window > Profiler 메뉴를 선택해서 프로파일러 창을 엽니다.
  • 프로파일러 창 상단의 툴 영역에서 Record를 선택합니다.
  • Play Mode로 들어갑니다.

이렇게하면, 게임에서 상호작용하는 동안 실시간으로 프로파일링 데이터를 모으고 표시해줄 것입니다.

게임을 개발 빌드로 프로파일링하기

타겟 디바이스에서 우리 게임의 프로파일링 데이터를 기록하기 위해서, 우리 게임의 개발 빌드를 만들고 프로파일러 창에 연결해야 합니다. 이는 타겟 플랫폼에 따라 어떻게 해야할지가 달라지게 됩니다.

Windows, OSX, Linux 그리고 WebGL

Windows, OSX, Linux 그리고 WebGL에서 개발 빌드를 실행하기 위해서는 다음과 같은 순서로 진행해야 합니다:

  • 프로파일링하고 싶은 프로젝트를 유니티에서 엽니다.
  • 상단 메뉴 바에서 Window > Profiler 를 선택해서 프로파일러 창을 엽니다.
  • 프로파일러 창의 툴 영역에서, Record를 선택합니다.
  • 상단 메뉴에서 빌드 설정(Build Settings) 창을 엽니다.(File > Build Settings).
  • Development Build를 체크하십시오.
  • Autoconnect Profiler를 체크하십시오.
  • Build and Run을 클릭하십시오.


[그림 10 : 빌드 설정 창]

게임이 타겟 디바이스에서 실행될 것입니다. 게임이 실행되면, 여러분이 게임과 상호작용하는 것이 유니티 에디터의 프로파일러 창에 표시될 것입니다.

iOS와 Android에 개발 빌드를 프로파일링하기

iOS와 Android에 개발 빌드를 프로파일러 창에 연결하는 것은 조금 더 복잡합니다. 왜냐하면 디바이스를 위한 빌드를 해야하고, 이 디바이스를 유니티 에디터에 연결해야하기 때문입니다.

iOS와 Android의 개발 빌드를 프로파일러 창에 연결하는 순차적인 방법은 유니티 매뉴얼의 문서를 참고하시기 바랍니다.

문제를 분석하기 위해서 프로파일러 창을 사용하기

이제 프로파일러 창이 어떻게 동작하는지에 대해 이해했으니, 이제 프로파일러 창을 이용해서 문제를 파악하는 방법과 어떻게 하면 이러한 문제를 해결하는데에 도움이 될 수 있는지를 알아야 합니다.

만약 우리 게임이 느리게 동작하거나, 프레임이 튀거나, 멈춤 현상이 발생한다면, 이 글이 프로파일러 창을 어떤게 사용하는지와 이러한 문제의 원인을 어떻게 찾는지에 대한 이야기를 해줄 것입니다.

728x90
Posted by 정망스
,
728x90

유니티 2019 공식 홈페이지를 보던 중에

모바일 알림 (프리뷰 패키지) 라고 하는 2019의 새로운 기능이라고 소개가 되어있는 글을 보게 되었다.

모바일 알림(프리뷰 패키지)

모바일 알림 프리뷰 패키지는 iOS(iOS 10 이상) 및 Android(4.1 이상)에서 반복적 또는 원타임 로컬 알림 스케줄링을 지원하여 리텐션 메카닉스 및 타이머 기반 게임플레이를 구현하는 데 도움을 줍니다.

 

기기에서의 로컬 알림을 지원하는 기능이 추가 되어 있는 것 같다. 

직접 네이티브 작업 없이 알림을 구현할수 있게 되었으니, 아주 편리하게 사용 할 수 있는 기능인거 같다.

로컬 알림..에 한해서지만 말이다, 그래도 로컬 알림 또한 자주 사용되는 기능이라고 할 수 있으니 소소한 편의를 기대해봐도 좋을 듯 하다.

간단한 기능 영상은 이걸 보면 된다. 

https://www.youtube.com/watch?time_continue=48&v=FLy06oRbTBI

 

728x90
Posted by 정망스
,
728x90

캐시 서버

Unity는 .psd 파일이나 .fbx 파일과 같은 에셋 소스가 변경되면 Unity는 변경사항을 감지하고 자동으로 다시 파일을 임포트합니다. 파일에서 임포트된 데이터는 즉시 내부 형식으로 변환되어 저장됩니다.

이 정렬 방식은 각 사용자 작업의 흐름을 최대한 효율적이고 유연하게 만들기 위해서 설계되었습니다. 그러나 팀으로 작업할 때는 다른 사용자들이 계속 변경하는 에셋을 임포트해야 하는 상황을 맞이하게 됩니다. 거기에 더해서 데스크탑에서 모바일 빌드 타겟 플랫폼으로 전환 시 에셋을 다시 임포트해야 합니다. 이러한 전환은 큰 프로젝트일 수록 더 많은 시간을 소모합니다.

임포트한 에셋 데이터를 캐시 서버 에 캐시하는 것은 에셋을 임포트하는 시간을 현저하게 줄입니다.


유니티를 사용하면서 느낄 수 있는 것은 새로운 에셋이 생기거나, 혹은 에셋에 변경이 생기거나, 혹은 컴퓨터에 처음 작업환경을 세팅하기 위해서 프로젝트의 최신판을 불러오는 등

캐시 서버를 사용하지 않으면 이러한 모든 과정이 로컬 환경에서 처리를 해야 하므로 그만큼 느려진다.

규모가 작아 양이 적은 프로젝트일 경우엔 문제가 없을 수 있지만, 규모가 커서 그만큼 양이 많다면 더더욱 이 부분이 작업을 하는 데 있어서 중요해질 것이다.

캐시 서버를 사용함으로써 에셋을 가져오는 시간이 줄어들기 때문에 플랫폼 전환 작업을 할 때도 시간을 매우 절약할 수 있고 생산성이 높아질 수 있다.

캐시 서버에 대한 자세한 정보는 공식 문서에 정리가 잘 정리가 되어 있는듯 하다.

https://docs.unity3d.com/kr/current/Manual/CacheServer.html

 

캐시 서버 - Unity 매뉴얼

Unity는 완전한 자동 에셋 파이프 라인을 가지고 있습니다. .psd 파일이나 .fbx 파일과 같은 에셋 소스가 변경되면 Unity는 변경사항을 감지하고 자동으로 다시 파일을 임포트합니다. 파일에서 임포트된 데이터는 즉시 내부 형식으로 변환되어 저장됩니다.

docs.unity3d.com

 

728x90
Posted by 정망스
,


맨 위로
홈으로 ▲위로 ▼아래로 ♥댓글쓰기 새로고침