function call 에는 run-time stack 을 만드는 비용이 추가됩니다.
이 비용도 꽤나 무시할 수 없기 때문에, loop 내에서의 호출이라던가..
그 빈도수가 높아지면.. 모두 오버헤드로 작용합니다.
반면 macro 에는 이 오버헤드가 없습니다.
그러나 macro 사용이 많아질수록, macro 코드가 전체 코드내에 중복으로 존재하기 때문에..
코드의 양이나 메모리 사용면에서 최적화 하기 어려운 면이 있습니다.
그 외에도 잘못 사용하면 유지보수를 어렵게 만들고..
디버깅 등에 문제를 일으키는 경우도 종종 있습니다.
매크로는 현금,
매크로는 현금, 함수는 신용카드.. 라면 설명이 될라나요.
물건 사러 나갔는데 현금을 내서 물건사는게 빠르죠(성능). 대신에 지갑에 부피를 많이(메모리크기) 차지합니다.
대신에 카드는 결제하는데 까지 시간이 오래걸리지만(성능), 대신 부피를 적게 (메모리크기) 차지하죠.
좀 어이없는 드립인가요 -_-;
일단 매크로가 전처리기에서 담당하는만큼 그만큼 컴파일시에 하는작업(준비)이 많아진다는 거고
메모리도 커지지만 속도는 빠르죠. 일반적으로 메모리를 많이 먹으면 먹을수록 똘똘하게 먹는 애들보다 빠르니깐요.;
정상적인 답변은 아랫분이...
음 ..
function call 에는 run-time stack 을 만드는 비용이 추가됩니다.
이 비용도 꽤나 무시할 수 없기 때문에, loop 내에서의 호출이라던가..
그 빈도수가 높아지면.. 모두 오버헤드로 작용합니다.
반면 macro 에는 이 오버헤드가 없습니다.
그러나 macro 사용이 많아질수록, macro 코드가 전체 코드내에 중복으로 존재하기 때문에..
코드의 양이나 메모리 사용면에서 최적화 하기 어려운 면이 있습니다.
그 외에도 잘못 사용하면 유지보수를 어렵게 만들고..
디버깅 등에 문제를 일으키는 경우도 종종 있습니다.
inline function(http://en.wikipedia.org/wiki/Inline_function) 과 같은 경우는 function 이면서도..
macro 와 비슷하게 function call 오버헤드를 줄일 수 있는 잇점이 있습니다.
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』
되면 한다! / feel no sorrow, feel no pain, feel no hurt, there's nothing gained.. only love will then remain.. 『 Mizz 』
함수를 호출하는
함수를 호출하는 경우,
인수들을 스택에 쌓고, 함수 콜을 하고, 다시 리턴하는 오버헤드로 인해 시간이 더 걸립니다.
대신 함수 하나만 만들면 되니까 메모리는 적게 듭니다.
마크로를 쓰면 번잡한 과정 없이 그자리에서 실행되므로 오버헤드는 없지만, 마크로 쓸 때마다 코드가 만들어지기 때문에 메모리를 많이 먹죠.
또, 마크로는 단순 치환이기 때문에 인수가 모두 evaluate 되는 것에 주의해야 합니다.
등가교환의 법칙.
"등가교환의 법칙!!"
"하나를 주면 하나를 얻는다!!"
Real world 나 Hello world 둘다 좋은게 좋은거고, 쉬운게 쉬운거면 좋겠지만...
함수를 매크로, 인라인함수로 바꾸고, 루프도 풀고,... 최적화란 말이 나올 때 항상 따라 나오죠.
http://en.wikipedia.org/wiki/Loop_unwinding
그러나, 매우 큰 사이즈의 함수, 소스 요기저기 안쓰이는 곳이 없는 함수를 매크로함수로 치환하면 바이너리 사이즈가 커집니다.
사실 바이너리 사이즈 몇 킬로바이트 커진다고 성능에 큰 영향(?)은 없겠죠.
그러나, 임베디드, 특정시간안에 라이브러리 물고 올라가야 하는 응용, 수백개의 프로세스가 운용중인 시스템,... 특수한 사항에서는 중요할 것 같습니다.
예로 폰같이 메모리를 제한적으로 사용하는 환경에서 메모리 상주 어플은 몇개 안됩니다.
만약에 사용자가 A 어플을 확인할려고 띄웁니다. 그럼, B, C, D 어플이 내려거야 합니다. 그리고, 다시 올라와야 하고요. 이런 어플이 멀티태스킹 환경이면 상당히 오버가 있습니다.
그래서, text 영역이 작은 쪽을 선호하죠. text 영역 특성상 일부 page 만 올렸다 내리기가 힘들죠.
결국 충분한 프로파일링만이 정답일 것 같습니다.
답변주신분들 감사합니다
(__)
댓글 달기