BCB 6를 오랫동안 사용해 왔습니다.
그간 데스크탑에서 개발할때는 별다른 문제가 없었는데,
노트북으로 개발할때 프로젝트가 커지면서 문제가 생겼습니다.

1. F9 로 실행시키면 어떤 때는 금방 실행되고 어떤 때는 한 10~30초 가량 멈춤현상이 생겼다가 실행됩니다.
이때 주로, 캡션바와 화면 일부를 그리다 말고 멈추어 있는 경우가 대부분입니다.
이때의 CPU 점유율은 거의 100% 수준이고 100%를 기록하지 않은 경우도 있습니다.

2. 프로젝트가 많이 커지면 실행시 어김없이 30-40초 가량 멈춤현상이 생기고 나서 실행됩니다.
또한 종료시도 원상태대로 돌아오는데 약 30초 가량이 또 걸립니다.

물론 개발중인 프로그램의 로직은 아무 이상 없으며,  IDE 디버그 모드를 해제하고 실행하거나,
그냥 탐색기에서 Make된 바이너리를 실행하는 경우는 아무런 문제가 없습니다.

문제는 디버깅을 위해 IDE 디버그 모드로 실행할 경우에 항상 일어난다는 것입니다.

이는 개발에 중대한 지장을 주는 것으로,
다른 사람의 경우를 찾아 보고, 인터넷 쪽에서 답을 일단의 검색을 해 봤지만 찾지는 못했습니다.

여러가지 개인적인 테스트를 한 결과,
문제는 IDE가 디버깅을 위해 실행 프로그램의 프로세스에 디버그 모드로 attach(달라붙는 것) 동작과
detach(떨어지는 것) 동작 과정의 직후와 직전에 일어난다는 것을 알았습니다.
IDE는 디버깅시 CPU에 디버깅 모드를 설정하고, 프로세스 메모리 전용 공간을 풀어서 접근할수 있게
조정하며 디버그 정보파일을 메모리에 올려 결합시켜 놓는 디버깅 준비와
종료시 이를 해제하는 과정을 수행합니다.

쓸데 없이 델파이 Forms.pas 소스 까지 살펴봤으나 동일 소스에 대해 델파이쪽은 문제가 거론된 적이 없었던
것으로 보아... 또한 멈춤이 일어나는 지점이 미미하게 달라진다는 점으로 보아
VCL이나 제작된 프로그램에 이상이 있는 것은 아니었습니다.

문제는 attach와 detach 동작시 마치 lock 이 걸린 것처럼 멈춤현상이 생긴다는데 있습니다.

일단의 해결방법은 성능 좋은 - 빠른 CPU와 1G 이상의 메모리, 빠른 HDD 를 갖춘다면
문제가 해결된다는 것입니다.

하지만 기왕이면 노트북에서 문제를 해결하고 싶더군요.

제가 사용하는 데스크탑의 경우는 1.5G P4 CPU에 512M 램인데 별다른 문제가 없고,
문제가 된 노트북은 1.8G P4 Mobile CPU에 512M 램, 데스크탑에 비해서 많이 느린 HDD 입니다.

그런데, 이 현상의 원인을 찾다가 발견한 사실은,
이 문제가 빌더 자체의 문제라기 보다는 OS와의 상호작용 사이의 문제라는 것입니다.

램이 512M이면 충분하지 않은 용량인데, 실행시 가상 메모리 페이징 파일로
스왑(메모리와 메모리 파일의 내용을 교환하는 일)이 일어나는 경우는
전체적인 OS가 매우 느려진다는 문제도 있습니다.


여기까지가 제가 파악한 내용입니다.
빌더에서의 개발 문제 중에 매우 중차대한 부분이라 생각되어 올립니다.
혹 잘못된 내용을 발견되거나, 새로 알게 되는 사실이 있으면 내용을 추가하겠습니다.
다른 의견이나 지적 사항은 리플 바랍니다.

//---------------------------------------------------------------------------
추가 수정 2.

오늘 원인을 드디어 찾았습니다.
빌더의 문제도 파일시스템의 문제도 가상메모리의 문제도 아니었습니다.
물론 가상 메모리 페이징이 일어나면 많이 느려지는 것은 사실이나
이것이 직접적인 이유는 아니었습니다.

실행시 딜레이 현상이 생기는 것중에
첫번째는 CPU를 100% 먹으면서 디버그모드로 실행할 준비를 하는 과정에서 지체되는 것이고,
두번째는 CPU는 0%에 가까운데 메인폼의 캡션바와 메뉴바 정도만 그려지고 10-20초가량 멈춰서 있는
경우가 있고,
세번째는 종료시 한 10-20초 멈춰서 있는 경우가 있습니다.

여기서 첫번째 문제는 컴 업글이 대안입니다. 첫번째 현상에 직면했다는 것은 자신이 개발 용도로
쓰고 있는 컴의 사양이 부족한 것입니다. 개인적으로 생각하기는
XP환경에서는 적어도 CPU 1.5G이상 램 1G 이상, 속도가 느리지 않은 HDD 정도는 갖춰야 할 것 같습니다.
Win2000의 경우는 램 512M에서도 무난했었습니다.

두번째 문제는 빌더의 디버그모드 하에서 발생하는 문제이지만,
결국 문제의 원인은 개발자가 찾아 제거할 수 밖에 없습니다.
저의 경우는 현재 컴퓨터의 IP를 얻기 위해 폼 생성시 아래와 같은 코드를 실행합니다.

    in_addr  inaddr = ClientSocket1->Socket->LookupName("");

이렇게 하면 inaddr 에 현재 컴의 IP가 담기게 되죠.
이 코드는 디버그모드가 아닌 경우는 거의 문제가 되지 않습니다.
하지만 디버그모드 하에서는 OS가 현재 자기 컴퓨터의 IP를 조회하기 위해,
일반적인 컴퓨터의 도메인네임 조회 방식을 사용하는 과정에서 일시적으로 시스템에 Lock을
거는데, 이때 디버그 모드하에서는 어떤 경우 Lock이 금방 풀리지 않아 10-20초 가량 지연되는 현상으로
나타납니다.
이 코드를 지우고 실행하면 지연현상 없이 여러번 실행해도 잘 동작하나,
이 코드가 있으면 10번에 한 3번 정도는 딱 멈춰서는 현상이 발생합니다.

결국 이 문제는 이와 유사하게 OS에 Lock 을 유발시키는 기능은 지연을 발생할 수 있는
가능성을 안고 있다는데 주목해야 합니다.
즉 위코드 뿐만 아니라, 특별한 환경의 개발 컴퓨터 상의 디버그 모드에서 지연을 일으킬 수 있는
코드는 더 있을 수 있다는 것이죠.

세번째는 저의 경우가 아니고, 다른분 중에 증상을 말씀하신 경우 입니다.
저는 겪어 보지 않아도 현재는 구체적으로 말씀을 드릴 부분이 없지만,
아마도 개발자 프로그램의 종료 프로세스 상에 문제가 아닌가 생각됩니다.
그렇다면 코드를 수정해 없앨 수 있겠지요.


이상의 문제는,
수 개월 동안 의문을 가지고 있었는데,
며칠전부터 문제를 밝혀보자는 결심으로 여러가지 실험과 인터넷에서 자료를 찾아 봤는데,
결국 가장 중요한 문제의 원인을 알아 정말 다행이군요. ^^;;;;
빌더의 모든 디버그 옵션 조정과  XP 환경 최적화,
수 기가 용량의 4만여개의 파일까지 다른 드라이브로 옮겨가며 실험했는데
... 머리가 돌이라서 겨우 알아 낸것 같습니다...

그럼... 참고하시고, 추가 사항이 생기면 또 달겠습니다.
혹 의견이 있으면 리플 바랍니다.