비주얼 스튜디오로 C# 프로젝트를 하나 만든 후, 마법사가 생성해 준 기본 폼 애플리케이션을 debug와 release로 제각기 모두 빌드하여 실행해 본다.
그 후 이 프로젝트 디렉터리의 크기를 측정해 보라. 본인은 200KB가 채 나오지 않았다.
그런데 C/C++ 프로젝트를 만들고(MFC는 쓰지도 않고), 그냥 간단한 창만 하나 띄우는 Win32 프로그램을 debug와 release로 모두 빌드해서 실행한 후 디렉터리 크기를 재 보라.
프로젝트가 차지하는 용량은 무려 20MB가 넘는다. (비주얼 스튜디오 2008 기준)
그렇다. C/C++은 프로젝트를 만들고 빌드를 좀 하면, 잡다하게 생기는 중간(intermediate) 파일이 엄청 많다. 게다가 용량도 상당히 많이 잡아먹는다.
<날개셋> 한글 입력기 프로젝트도 32비트 디버그/릴리스, 그리고 64비트까지 빌드하다 보니 디렉터리 전체 크기가 무려 800MB에 달해 있다. 하지만 그 중 실제로 빌드에 쓰이는 소스나 데이터 파일의 합은 20~30MB대는 절대 안 넘을 것이다. -_-;;
OBJ 파일이 생기는 것이야 C/C++ 자체가 링크를 염두에 두고 만들어진 언어이니 어쩔 수 없고 그건 어차피 그렇게 크지도 않다. ..... 라고 말하려고 했는데, 오브젝트 파일도 각종 디버깅 내지 고급 최적화와 관련된 메타정보가 첨가되다 보면 단순히 소스 코드의 기계어 번역이라고 볼 수 없을 정도로 덩치가 은근히 커지긴 한다.
OBJ 말고도 디스크 용량을 상당히 차지하는 주범은 잘 알다시피 pre-compiled header이다(*.PCH) 겨우 몇몇 개의 헤더 정도나 인클루드하면 되는 정올 답안 수준의 프로그램이 아니라 특정 운영체제/플랫폼이나 거대한 라이브러리의 프로그래밍 요소를 다 인클루드하는 프로그램이라면, 그렇게 고정불변이고 덩치가 많은 요소들은 미리 컴파일을 좀 시켜 놔야지 프로그램의 빌드 시간을 줄일 수 있다.
본인이 비주얼 C++을 처음으로 쓴 게 4.2 시절부터이다. 그때엔 MFC 심볼들을 다 빌드해 놓은 pch 파일도 이미 3~5MB 정도 했던 것 같다. 하지만 지금은 그것보다 덩치가 훨씬 더 커져 있고 한 빌드 configuration당 10MB는 훌쩍 넘어간다. 프로젝트 하나 만들 때마다 50~100MB씩은 잡아야 한다. 오로지 C/C++ 언어 프로젝트만이 이런 삽질이 필요하다.
윈도우 SDK나 MFC처럼 매 프로젝트마다 일일이 빌드가 필요하지 않은 것들은 공용 PCH라는 개념으로 공유만 좀 하게 해 놔도 이런 파일의 크기를 상당 부분 줄일 수 있을 텐데 너무 낭비라는 생각이 든다. 하지만 요즘은 하드디스크 용량이 워낙 많다 보니, 빌드 시간을 네트워큭 분산 기술을 줄이려는 연구는 해도 PCH 파일 크기를 줄이려는 연구는 거의 행해지지 않는 것 같다.
이외에도 인텔리센스 데이터베이스인 NCB 파일도 은근히 크고, 매 빌드 때마다 생기는 심볼 디버그 데이터베이스인 PDB 파일도 무시 못 한다.
왜 이런 일이 생기는 것일까? 대략 다음과 같은 관점에서 살펴볼 수 있다.
첫째, C/C++은 굉장히 작은 언어이고, 프로그래밍에 필요한 요소들을 전적으로 소스와 동일한 텍스트 포맷인 헤더 파일의 파싱(느림!!)에 의존하여 읽어들이는 형태이기 때문이다. 라이브러리 링크는 별도의 계층으로 따로 존재하지, 즉시 읽어들일 수 있는 바이너리 유닛/패키지라든가(파스칼, 자바, C# 등) 언어가 자체 내장하고 있는 요소가 없다. 원천적으로 이식성을 택했지, 속도를 배려하지는 않은 느린 프로세스를 사용하는 셈이다.
둘째, C/C++은 전처리기라든가 링크 과정으로 인해 빌드가 더욱 느리고, 언어의 해석이 더디기 때문이다. 모든 토큰은 그냥 토큰이 아니라 전처리기를 재귀적으로 거치면서 다 까 봐야 실체가 드러난다. ^^;;; 헤더 파일의 글자 하나를 고치면 이 여파가 수백, 수천 개의 소스 파일에 동시에 파급되고 프로그램의 의미가 전혀 다르게 바뀔 수 있다. 이것은 장점도 있지만 똑똑한 개발 환경이나 빠른 빌드 환경을 만드는 데는 불리한 구조이다.
그러니, 소스 코드를 조금이라도 빨리 분석하기 위해서는 소스코드 자체뿐만 아니라 온갖 메타정보들을 ‘별도의 파일’로 보관할 수밖에 없다. NCB처럼 말이다.
셋째, C/C++은 그 어느 에뮬레이터나 가상 기계 계층이 없이, CPU 차원에서 기계가 직통으로 알아듣는 프로그램을 만들 수 있다. 잘 최적화된 프로그램은 사람이 원래 짠 소스 코드와는 전혀 다른 형태가 될 수도 있다. 그러니 이런 코드의 디버깅은 어려울 수밖에 없다. 변수의 내용을 확인하거나 한 줄씩 실행하는 것까지는 못 하더라도 프로그램이 뻗었을 때 스택 덤프라도 보려면 빌드된 프로그램과 소스 코드 사이의 관계를 설명하는 최소한의 정보라도 있어야 한다. 소스 코드와 형태가 전혀 딴판인 코드를 생성하는 컴파일러일수록 그런 정보는 더욱 세부적이고 양이 많아질 수밖에 없다.
한 마디로 C/C++이 정말 강력하고 포괄적이고 대인배 같은 언어이다 보니 주변에 붙는 군더더기도 많은 모양이다. ^^ 코드 생성이 여러 단계를 거치면서 매우 번거롭고 어려운 대신, 한번 만들어 진 코드는 그 어느 언어보다도 강력하다.
Posted by 사무엘
