Making your code more portable by avoiding inlining???

요새 컴퓨터 속도의 증가로, 소프트웨어를 디자인 하는데 있어서 퍼포먼스의 측면보다는 유지 관리 보수를 하는데 초점을 맞춘 디자인을 하는 경향이 있다고 한다. 그렇다고 퍼포먼스를 전혀 신경쓰지 않을수는 없겠지만, 예전에 비해서는 퍼포먼스의 측면을 덜 따지기 시작했다는 뜻일 것이다...

성질 급하신 분들을 위해서 이 글에 대한 설명을 먼저 하자면...

내가 최근에 봉착한 문제는 정말 쥐꼬리만큼의 퍼포먼스의 이득을 보기 위해서 사용한 inline function들이, 코드의 portability를 떨어뜨리는 결과를 낳게 되었다는 것이다... 아직까지는 내 추측이지만, 그 문제 때문에 이틀간의 삽질이 계속되었다...

나는 현재 다른 사람이 짜놓은 프로그램에 어떤 기능을 추가하는 일을 하고 있다. 그 과정을 좀 쉽게 하기 위해서 꼼수를 써서, 기존에 없던 가상의 layer를 구현 함으로써 그 layer를 통해서 원래 하고자 하는 함수들을 호출하게 하고, 그 과정에서 내가 새로 추가해야 하는 기능들을 구현하기로 하였다. 회사에서 하는 일이라서 구체적으로 어떤 일을 하고 있는지 말하기는 좀 그렇다... 하지만 도식적으로 나타내자면 대충 이렇다...

어쨌든, 문제는 이랬다...

하나의 layer를 추가하게 됨에 다라서 함수 호출하는 일이 더 많아지기 때문에 추가된 함수 호출에 의한 overhead를 최소한으로 줄이기 위해서 나는 inline이라는 키원드를 사용해서 내가 구현한 부분은 main()에서 호출할때 inline으로 호출하도록 하였다. 퍼포먼스의 영향을 많이 주지 못할것을 뻔히 알면서 그냥 뭔가 있어보이려고 시도했다... 하지만 계속 빌드를 하면 최종 결과물인 so(shared object) file을 linking하여 생성할때 내가 추가한 함수들에 대한 reference를 찾을 수 없다는 것이다. ㅡ.ㅡ;

이틀간 삽질 끝에 곰곰히 생각해보다가... 막연히 결과물이 shared object file이라는 점과 내가 inline을 사용했다는 점이 떠올라 inline keyword를 모두 지워버렸더니 그런 linking 에러가 없어져버렸다는... 물론 그 문제가 어느정도 해결되면서 다른 build error들이 발생하였지만, 이틀간 거의 밤새고 그 문제를 태클하던 터라 일단 쉬기로 하였었다...

한숨 자고 친구 결혼식 다녀와서 집에 내려가서 쉬다 왔는데도 오늘 하루종일 졸렸다... 지금도 일하러 사무실에 나왔는데, 배만 고프고 졸립다 ㅜ.ㅜ;

어쨌든, 그러니까 inline function을 사용한 것이 shared object library를 생성하는데 문제가 된다면, inlining은 code의 portability에 문제를 가지고 온다는 말인데... 내가 생각한 문제가 맞긴 맞나? 문제를 찾긴 찾은거 같은데, 아무리 결과가 shared object library file이지만, inline이 문제가 되나??? build하는 방식에 문제가 있나??? 좀더 확인해 봐야 할 것이 많은데도 불구하고, 졸립고 피곤하고 배고프고 귀칞아서 일단은, 누군가 이 문제에 대해서 글을 써서 트랙백을 달아주거나 리플을 기다려보고, 나중에 더 파고들어봐야겠다...

아~ 석사학위까지 있는데, 참으로 부끄럽다... 

고수님들 알려주세요 ㅡ.ㅡ;

Orz