 |
|
|
|
 |
 |
 |
 Early Binding 과 Late Binding
|
| Early Binding은 vtable에 서버 객체의 프로퍼티나 메소드의 메모리 주소를 두고 Client가 접근할 때 이를 이용하는 빠른 접근 방법을 제공합니다. Late Binding은 속성이나 메소드 이름을 통하여 얻은 dispatch ID를 통해 접근하는 방법으로 접근 속도가 느립니다. Microsoft 는 이를 보완하기 위해 이 두 가지 방법을 같이 쓰는 dual interface를 권고하며 GOM 에서는 dual interface 를 지원하기 때문에 두 가지 방식의 사용이 모두 가능합니다. 그러나 HTS는 속성상 빠른 속도가 필요로 하고 많은 접근 횟수를 필요로 하므로 사용자들에게 Early Binding 을 권하는 바 입니다. |
|
객체의 접근 횟수
|
| 무엇보다도 클라이언트 제작시 유의점은 최소한의 CPU 로드를 줄이는 것입니다. 이는 서버, 클라이언트의 원활한 동작을 보장하므로 클라이언트를 작성하고 동작을 시키면서 자주 프로세서(CPU) 가동율을 확인하는 것이 좋습니다. 프로세서 가동율이 100%가 계속 유지가 되면 클라이언트가 할 일들이 수 초간 지연 되거나 프로그램이 멈추어 있는 현상, 이벤트 수신 실패등 문제가 발생하므로 프로세서(CPU) 가동률을 자주 점검해야 합니다. COM 객체의 메소드, 속성의 접근은 동일 프로그램 내의 객체 접근보다 부하가 훨씬 드는 작업입니다. 이는 다른 프로세스 간의 통신을 위해 우리 눈에는 보이지 않는 많은 작업이 존재함을 의미합니다. GOM 도 COM 객체 이므로 이와 같은 부하의 문제에 자유로울 수 는 없습니다. 그래서 클라이언트는 GOM 객체에 대한 접근을 최대한 줄여야 합니다. 이를 테면 클라이언트의 모듈에서 GxSymbol의 현재가가 여러 번 필요하다고 가정합니다. 이런 상황에 클라이언트가 현재가가 변경되지 않은 상태에서는 서버의 GxSymbol 객체의 현재가 속성을 여러번 호출하는 것보다 한 번 접근하여 그 값을 클라이언트 내에서 저장하고 그 값을 사용하는 것이 부하를 경감하는 방법 일 수 있습니다. |
|
이벤트 핸들러
|
| COM 이벤트 수신 작업을 약간 살펴 보면 서버측에서 이벤트를 발생 시키면 서버측은 멈추게 되어 클라이언트는 제어권이 순간적으로 넘어 갑니다. 이 때 클라이언트의 이벤트 핸들러를 실행하고 핸들러가 종료되면 다시 서버로 제어권을 넘기게 됩니다. 이는 클라이언트의 이벤트 핸들러가 마칠 때까지 서버가 멈추게 되는 의미이므로 클라이언트는 이벤트 처리를 빠른 시간 내에 마쳐야 합니다. 윈도우 메시지가 사용 가능한 Language는 윈도우 메시지를 날리고 이벤트 핸들러를 바로 마쳐서 제어권을 서버에 넘겨주고 윈도우 메시지를 받아 실제 이벤트 핸들링을 하는 방법이 좋습니다. 그리고 이벤트 핸들러 상에서 부하가 많은 작업이나 모달 다이얼로그를 띄우는 것은 절대 피해야 합니다. 모달 메시지 다이얼로그는 제어권을 멈추어 버리게 하여 서버를 멈추게 합니다. 그리고 이벤트 핸들러상에서 꼭 Exception 핸들링을 해야 합니다. 이벤트 핸들링 과정에서 에러가 발생하여 에러 창등이 나타나는 현상도 서버를 멈추게 합니다. |
|
EventFiltered 사용
|
EventFilter 사용하지 않는 경우의 CPU ( 숫자는 초당 입력 시세 건수)
EventFilter 사용하는 경우의 CPU ( 숫자는 초당 입력 시세 건수) |
{window.open('/inc/inc_img.html?img=/cheditor/attach/WjiBMKYGVfIA9hd2E.jpg','img_view','width=1,height=1,resize=yes'); return;}img_view();)
{window.open('/inc/inc_img.html?img=/cheditor/attach/PJlT1aBJAWDP6LMsZk9t.jpg','img_view','width=1,height=1,resize=yes'); return;}img_view();)
|
GxChartStore 관리
|
| GxChartStore 는 'Add'를 하여 GxChartData를 생성시킵니다. 만일 많은 수의 'Add'를 하고 이에 대해 이벤트 요청을 하면 프로세서 부하나 메모리 문제등이 발생할 수 있습니다. 그래서 GOM에서는 GxChartData의 갯수 상한치를 100개로 지정하고 이 이상의 'Add'를 할 경우 NULL을 반환하지만 사용하지 않은 GxChartData는 GxChartStore의 Remove나 RemoveByKey를 사용하여 제거하거나 GxChartData의 UnDefine을 사용, 이벤트 중지등을 사용하는 것이 좋습니다. |
|
UI 작업과 I/O 작업
|
| 이곳에서는 프로그래밍 전반에 대한 요령을 얘기 하겠습니다. 프로그래밍에서 부하를 많이 잡는 작업으로는 I/O(예:파일작업), UI 작업등이 있습니다. UI 작업은 화면에 나타나게 하는 작업인데 Optimize 작업을 소홀히 하면 이 작업에서 많은 부하를 잡게 됩니다. 예를 들어 MSFlexGrid 컨트롤같은 경우 빠른 시간내에 현재 포커스되어 있는 셀을 계속 바꾸어가면서 셀의 색깔을 바꾸는 작업등은 부하를 굉장히 많이 잡습니다. 그리고 시세를 수신함과 동시에 파일을 저장하는 작업등도 피해야 합니다. 일반적인 그리고 프로그래밍에서 부하 처리는 굉장히 중요한 문제 이므로 GOM 사용자 분들은 이에 신경을 많이 써 주시기 바랍니다. |
|
고수시스템의 변경시 작업
|
| 서버나 고수의 배포가 발생할 경우는 GOM에 대한 테스트가 필요합니다. GOM 사용자분들은 고수의 배포내역과 공지내역을 꼭 확인부탁드리고 이에 대한 적절한 조치를 꼭 하시기 바랍니다. |
 |
 |
 |