C#으로 그냥 TextBox 몇 개 있는 Form을 띄우는 코드를 만들고 가만히 보고 있었습니다.
그런데, 잘 보니 이상한 점이 있더군요.

먼저 폼이나 텍스트박스에 관련된 속성들을 InitializeComponent 함수에서 싹 처리합니다.
그런데 저 함수는 단순히 폼 생성자에서 호출하죠.
실질적으로 실행되는 문장은 new로 그 폼을 만들어서 Application.Run에 넘겨주는 것 뿐이지요.

어디에도 실제로 폼을 띄워주는 부분이 없습니다.

그래서 궁금해서 무작정 F11을 눌러봤습니다.
코드야 MSIL인지 뭔지겠지만 결국 JIT로 기계어로 대충 번역된 것을 들여다 봤지요.


위 호출 스택을 보시면 아실 수 있듯이...
Application.Run에서는 프로그램의 메시지 루프를 돌리는 부분이 들어있습니다.
그리고 인자로 넘긴 폼을 보여주는 것 같더군요.
그 폼을 보여주기 위해서 Visible 속성을 true로 설정하는 부분부터 쭉 시작해서...
결국 내부적으로 ShowWindow를 호출해주고... ControlNativeWindow라는 놈(.NET은 이런 이벤트를 위해 메시지만 받는 창 하나를 또 만들어 놓는듯...)을 거쳐서 그 폼에 갔다가, 베이스로 자꾸 넘겨서 결국 System.Windows.Forms.Control까지 가는 겁니다.
그 상태에선 아직 실질적으로 창이 만들어진게 아니니까 CreateControl 호출해서 창 만들고, 그리고 그 안의 컨트롤까지 만드는 부분...에서 그냥 껐습니다.

이런걸 보면서 제가 느낀 점은...

1. 닷넷엔 인라인이 없다?
일단 무조건 함수를 호출하는 근성을 보여줍니다.
예를 들어 Handle 속성을 가져오도록 하면 get_Handle 함수 호출로 바꾸고 그 안에서 이리 저리 꼬아서 핸들을 하나 리턴합니다.
이건 VB 6도 그러던데 아무래도 닷넷이 COM 기반이라 그런 것 같군요...

2. "관리되는 형식"을 너무 관리해준다?
저 코드까지 도달하는데만 핸들이 0인지 비교한다거나...하는 단순 숫자 비교가 수 십번 나왔었는데,
그때마다 어떤 함수를 자꾸 호출해서 비교하더랍니다.


딱히 느리다는 것을 탓하려는건 아니지만, 이건 거의 "이렇게까지 했는데도 문제가 발생하면 울어버릴 정도로" 해놨더군요.
속도를 희생해서 말이죠. -_-;
물론 C# 같은 언어에서 생성되는 코드가 느리다는게 아니라, .NET 라이브러리가 그렇게 생겨먹었다는 소립니다. -_-;



이제야 왜 닷넷에서 폼 하나 덜렁 뜨는 프로그램을 만들면 실행했을 때 폼이 탁 뜨기까지 걸리는 시간이 살짝 길다싶었는지 그 이유를 확실히 알 것 같군요 -_-;
(바보같은 짓일지도 모르지만, 닷넷에서도 기존 방식처럼 API 써서 창 띄우면 그렇게 느리게 뜨지 않습니다 -_-)



그나저나 .NET에서 창과 메시지 구현해주는 시스템은...
구조적으로 참 멋집니다.
근데 어찌 그렇게 델파이에 있는 VCL과 함수 이름, 구조체 이름 하나 하나가 그리 비슷하죠 -_-;
전율이 일 정도입니다.
솔직히 .NET은 아무리 봐도 MFC를 만들었던 MS가 생각한 것 같지가 않은 구조라서 -_-
.NET 개발팀 중에 델파이 만든 사람 있다는 소릴 들은 것 같은데 사실인가보군요 -_-

하여간 VCL이나 MFC같은, "좀 비주얼~하게 프로그래밍 해보자!" 하는 느낌의 소규모 라이브러리를 만들고 있다가 이것 저것 참고 중에 잠깐 적어봅니다.