여기에 정리하는 글들은 모든것이 정확한것은 아니다.
나중에 참고할 것을 대비해서 정리하는 글이다..
1. for vs foreach vs enumerator
foreach와 enumerator 이 두개간의 성능은 거의 차이가 없는듯하다 굳이 따지자면
enumerator가 미세한 차이로 좀 더 속도가 빠른것 같다.
for 같은 경우엔 foreach와 enumerator 보다 약 1.7~1.8배 정도 속도가 더 빠른것으로 보인다.
예전엔 foreach를 쓰게되면 gc남게 되어 속도도 for 보다 느리고, gc까지 생기니 사용하는데 있어서 좀 그랬다하면.. 최근에는 그래도 gc는 안생기는거 같아, 부분적으로 필요할때 사용해도 문제는 되지 않을 것 같다.
좀 더 자세히 보니, unity 5.5이전 버전까지는 foreach 루프에서 발생하던 박싱 작업이 가비지를 만드는 원인이였다고 하는데, 5.5 이후 버전부터는 c# 컴파일러가 업그레이드 되면서 박싱 작업이 제거되어 가비지는 발생하지 않는다고 한다. 하지만 속도면에선 여전히 제일 느리다..
2. int -> string, string -> int
int -> string은 별 차이가 없는거 같다. 흔히 사용하는 toString(), System.Convert.ToString() 등 아무거나 사용해도 될듯 하다.
string -> int은
주로 쓰는 parse와 tryparse를 놓고 볼떄 속도만 놓고보면 parse가 빠르다는거 같은데 그 차이는 진짜 미미한 정도라고 하는거 같다. 차이라면, parse 같은 경우에는 올바르지 않은 파라미터값이 들어가면 예외를 던져서 프로그램이 죽는다는 것이다.
굳이 이런 미미만 속도에 미련이 없다면, tryparse를 사용해서 자체적으로 예외처리를 할수 있게끔 하는것도 좋은것 같다.
3. delegate
c#을 하다보면 delegate를 사용하여 익명 함수를 파라미터로 넘겨주는 그런 코드를 자주 작성하게 된다.
파라미터로 받은 delegate 함수를 실행할경우 delegate가 null이거나 빈내용일 경우, 함수를 실행을 안하도록 하는것이 성능과, 속도면에서 좋은것 같았다. ( 쓰고보니 당연한 얘기 같음.. )
딱히 실행할 내용이 없다면 빈 delegate를 넘겨주지 않도록 하고, 받는 쪽에선 null체크를 하고 null일시 실행을 안하도록 하는 식으로 하는것이 좋을것 같다.
4. transform
속도만 놓고 봤을땐 transform에 대한 접근을 그때마다 하느냐, 아니면 캐싱을 해서 가지고 있는것으로 사용하느냐는 캐싱을 하고 사용하는것이 훨씬 빠르다고 한다.
하지만 사용법에 따라 늘 접근 방법은 다를수 있으므로, 필요할 시엔 그때마다 접근을 하되 자주 transform을 접근하는 상황이라면 캐싱을 해야될 것 같다.
5. Log
코딩을 하면서 수많은 Debug.Log, warning 등등 많은 로그들을 남겨둔다.
로그는 많은 비용을 차지하기 때문에 반드시 개발이 완료된 후나, 개발 도중이라도 사용되지 않을 로그들은 제거해주는것이 좋을 것 같다.
6.Equals vs ==
여러 블로그를 보고 정리한 결론에 따르면
결론은 둘다 Equals 메소드에 의해 수행 된다는 것이고 경우에 따라 ==가 빠를수도, Equals가 빠를수도
있다고 하니, 사실상 둘의 성능 차이는 미미하다고 봐야될 것 같고 차이가 없다( .Net언어에서 ) 라고 정리 해야 될 것 같다.
굳이 차이라면 == 은 서로 타입이 다르면 컴파일에서 오류가 나고,
equals는 객체를 받아들일수 있다는 건데, equals는 내부적으로 보면 결국엔 object를 string 형으로 as 해서 변경하고 있고, string이 아니라면 null값을 넣어 버린다.
즉 ==은 형이 다르면 곧바로 오류지만, equals는 일단 객체에 대한 비교까지는 한다는 것이다.
그리고 equals도 결국엔 형이 같은 경우 값을 비교해서 결과를 낸다는 것뿐
결론은 같다는 것이다..
--------------------------------------------------------------------------------------
위 얘기는 string(문자열) 비교일 경우에 해당하는 정리 글일 뿐
== 연산자를 다른 object 형에서 사용하게 되면 value 값 비교가 아닌 reference 비교를 한다는 점이다.
문자열이라면 == 을 사용할 경우 equals를 부르고 값을 비교하는 거지만, 다른 형들은 아닐 수도 있다라는 것을 기억하고 있어야 한다.
7.string 연결
+ == string.concat() 둘다 string.concat으로 컴파일 된다. +연산자는 오버로드되서 concat을 수행한다. 즉 이 둘의 차이는 없다는 것.
stringbuilder은 많은 수의 문자열이 연결될 때만 적합하다는것 같다.
string.format은 실제로 stringbuilder을 사용하여 구현되므로 느리다.
a + b + c 를 하는 경우에
a,b,c,ab, abc 다섯개가 문자열이 메모리에 생성되고
필요없는 문자열들은 하나씩 지워나간다 즉 쓸때없는 gc를 만들어 낸다
stringbuilder을 사용하면 ab를 얻지 않고 abc만 얻으므로 gc 효율면에선 더 좋다
속도면에선 +, tostring() 이 stringbuilder보다 빠르다고 한다.
적절히 문자열 길이에 따라 알아서 쓰면 될듯..하다
'Unity' 카테고리의 다른 글
| 유니티(Unity) 에셋번들(AssetBundle)과 관련된 정리中... (1) | 2018.02.20 |
|---|---|
| 유니티(Unity)(C#) 개발하면서.. 몰랏던거나 유용하거나 자주쓰일것 같은.. 것들 정리中 (0) | 2018.02.08 |
| [NGUI] depth 관련 해서.. 혼자 정리 (0) | 2017.01.23 |
| 유니티랑 nodejs 간단 연동 테스트 해보기. (1) | 2016.10.31 |
| [펌] 유니티 리소스들 최적화 TIP (0) | 2016.08.04 |
UnitySocketIO-master.zip
