질문의도가 프로그램 실행하고 윈도우의 작업관리자에서 메모리 점유율을 보시고
말씀 하신것 같네요 실행화일의 크기가 아니라...
한마디로 말하면 이거 원래 그래요 ^^
폼을 가지고 있는 프로세스는 다 그렇다고 보면 무방..
그리고 폼이 Maximize 될때의 메모리 사용량과 Minimize 되었을 때의 메모리 사용량을
보세요 Minimize될때에는 500K도 안 먹을꺼에요
윈도우 O/S 아니 다른 O/S 포함 해서 ^^ 모든것들은 다 그렇다고 보세요 ^^
모니터상에 하나의 점을 표현할때에는 B/W(이건 LED 할때 사용하죠 ^^)일때는 1bit
256칼라를 표현할때는 1Byte 65,000칼라는 2Byte , 현재 일반적인 24bit Color를
표현할때 3바이트죠 ^^
그럼 단순히 화면에 그림하나 그리는 것을 생각 해보죠 (어차피 O/S 입장에서는 스크린에 표현
되는것들은 모두 그림입니다.)
1280 X 1024 X 24bit Full 화면에 뛰운다고 가정하면 3,932,160 Byte 가 그 프로그램에
리소스로 점유하여 사용하게 됩니다. 거의 4메가죠 ^^
이 외에도 윈도우 폼으로써 작동되기 위한 기초적인 리소스는 많습니다만 저것이 가장 클꺼에요..
이것들이 가변적으로 점유하여 들어갑니다.
결론적으로 말하면 델파이가 아닌 어떤 언어로 작성하더라도 말씀하신 메모리는 차지 합니다.
이것이 정답입니다.
버튼 하나가 5메가를 차지하는 것이라서 그런 것이 아니라 리소스를 비롯하여 많은 것들이 기본적으로 추가되어서 그렇습니다. 리소스를 제외하시고 폼으로 하시기보다 API를 쓰시거나, 컴파일시 디버그 관련 정보를 제외하신다면(?) 실행파일의 용량 절감과 함께 메모리 점유도 낮아지지 않을까 합니다.
말씀 하신것 같네요 실행화일의 크기가 아니라...
한마디로 말하면 이거 원래 그래요 ^^
폼을 가지고 있는 프로세스는 다 그렇다고 보면 무방..
그리고 폼이 Maximize 될때의 메모리 사용량과 Minimize 되었을 때의 메모리 사용량을
보세요 Minimize될때에는 500K도 안 먹을꺼에요
윈도우 O/S 아니 다른 O/S 포함 해서 ^^ 모든것들은 다 그렇다고 보세요 ^^
모니터상에 하나의 점을 표현할때에는 B/W(이건 LED 할때 사용하죠 ^^)일때는 1bit
256칼라를 표현할때는 1Byte 65,000칼라는 2Byte , 현재 일반적인 24bit Color를
표현할때 3바이트죠 ^^
그럼 단순히 화면에 그림하나 그리는 것을 생각 해보죠 (어차피 O/S 입장에서는 스크린에 표현
되는것들은 모두 그림입니다.)
1280 X 1024 X 24bit Full 화면에 뛰운다고 가정하면 3,932,160 Byte 가 그 프로그램에
리소스로 점유하여 사용하게 됩니다. 거의 4메가죠 ^^
이 외에도 윈도우 폼으로써 작동되기 위한 기초적인 리소스는 많습니다만 저것이 가장 클꺼에요..
이것들이 가변적으로 점유하여 들어갑니다.
결론적으로 말하면 델파이가 아닌 어떤 언어로 작성하더라도 말씀하신 메모리는 차지 합니다.
이것이 정답입니다.
그럼 이만 바이바이..