대미지 표시를 파티클 기반으로 구현하는 작업을 하던 도중에
본래는 toString으로 대미지 값에 해당하는 문자열로 만드는 방식을 사용했었는데,
toString이 무조건 gc를 만든다는 사실을 알게 되었고 이걸 Span과 stackalloc으로 대체해서
char 배열을 스택에서 할당해서 사용하는 방식으로 최적화?를 하려고 했습니다
프로파일러를 써보는 게 처음이기도 하고
스택 오버플로우라는 개념에 대해서는 자주 듣긴 했지만
정작 그래서 스택을 얼마나 보수적으로 사용해야하는지 모르겠어서 여쭤봅니다 ;ㅅ;
아래는 인게임 씬 시작 직후 대미지 텍스트를 초당 1000개씩 강제로 출력하는 환경에서 비교해본 결과입니다
이정도 차이라면 그냥 힙에서 배열 할당해서 쓰는 게 맞을까요..?
1.니가 구현하려는게 메모리 문제를 일으켰음? 2.아무문제 없었다면 쓸데없는짓 하지마셈. 3.가비지컬렉터를 통제하려는 시도 자체가 애초에 닷넷이 뭘 목적으로 만들어진 어떤특성의 언어인지를 망각한 유사cpp 개짓거리 하는거임 넌 절대 가비지컬렉터를 통제할수 없음 메모리가 터졌다면 니가 설계를 ㅂㅅ처럼 한거고 설계자체를 바꿔야됨
4.코딩연습 목적이면 걍 프로그래밍갤 가서 질문 여긴 게임만드는데고 구현과정에 필요한 문제를 질문하는데지 코딩깔짝갤이 아님
아..앗.. 조언 감사합니다 ㅠㅠ 공부한 셈 치고 원래 걸로 그냥 쓸게요...
스판 잘쓰면 조아여 대신 스판이 코드의 복잡도를 올리지 않도록 잘 감싸야함
글고 만약 숫자가 1억이 넘어가면? 천단위마다 쉼표를 넣어야 한다면? 상황은 어떻게 될지 모르므로 지금 시점에 최적화는 R&D하는 정도에서 멈추는게 좋을거 같아여 게임 구현 다 하고 끝에가서 최적화ㄱㄱ
조언 감사합니다..! 일단 여기까지만 하고 다음으로 넘어가보겠습니다 ㅎㅎ;;
과학실험이랑 같음. 비교군이 없는데 실험을 하면 아무 의미가 없음
해결 하겠다 선언은 했지만 당장은 유니티 gc가 좀 븅이라 걱정 좀 하긴 해야 하는 것 자체는 맞음 근데 보통은 게임오브젝트 같이 유니티 관련 문제가 걸리지, 네 문제의 경우는 실제 gc가 그 쪽에 많이 잡힐 때 해결하면 됨 질문에 대해 답을 하자면 스택 메모리는 보통 최대치를 2mb로 잡음 char 몇백 개 잡는 거로는 문제 생길 일은 없음 그럴 일은 잘 없지만 문제 생길 정도로 메모리를 써야 한다면 list를 재사용 하거나 arraypool로 쓰면 됨
덧붙여서 tostring으로 성능 잡아 먹을 정도면 눈에 확 띔 예를 들어서 enum의 경우 tostring이 리플렉션 사용하는터라 프로파일러 자체에서 쓰지말라고 주의 띄우던걸로 기억함
오오 궁금했던 부분들인데 설명 감사합니다!!