본문 바로가기
IT-개발,DB

[IT/개발] 파워빌더 프로그램의 성능관리

by SB리치퍼슨 2010. 7. 8.

파워빌더 성능 관리
 
근래에 파워빌더로 개발된 곳에서 성능 측정을 요구하는 곳이 많아 지원을 가보면 
일반적으로 고려하여야 할 사항을 무시하고 개발된 곳이 대부분이라 성능이 문제가 되고 있었다.

파워빌더의 문제라기보다는 파워빌더에 맞는 고려사항을 인지하지 못한 탓이다. 
이런 이유로 고객의 요구에 의해 본사에서 시행하는 성능관리 교육교재를 요약하여 싣는다.

(Managing Performance in 
     PowerBuilder)
 
목차 
 
1 장: 
     개요

2 장: 
     해당 실행 모듈 호출

3 장: 
     스크립트 실행 

4 장: 
     데이터 조회

5 장: 
     그 외 사항 
 
1 장: 
     개요
 
성능 이란 
       ?

성능과 관련된 문제점과 토론 사항

성능 향상 정책 수립

사용자 인식 관리

  
 
1.1 
       성능이란 ? 
 
사용자 관점의 성능
성능이라는 것은 실행 시 얼마나 빨리 시스템이 응답하느냐는 것이다. 

개발자 관점의 성능
성능은 다음과 같은 사항을 고려 

서버의 부하
네트웍의 거리
사용자 수
클라이언트와 서버의 구성
데이터베이스 설계와 정규화
애플리케이션의 설계와 작성
사용자의 인지도 
1.2 
       일반적인 성능 불만 사항 
 
윈도우를 열 때 
데이터 조회 시 
애플리케이션 실행 시
필드간 이동 시 
윈도우 간 이동 시
계속하여 실행 시
 
 
1.3 
       문제 발생 요인 
 
해당 실행 모듈 호출
스크립트 실행
데이터 조회
하드웨어와 소프트웨어 구성 
1.4 
       성능 향상 정책 수립 
 
문제점 분리
문제점 범위 지정
이벤트
함수
과정
기능
모든 것이 느리다는 것은 용인되지 않음 
 
 
1.5 
       애플리케이션 환경 점검 
 
애플리케이션의 문제인지 구성 문제인지 ? 
보다 더 성능이 뛰어난 기계에서 실행
관련 모듈을 클라이언트에 설치 
 
 
 
 
1.6 
       설계 재점검 
 
잘못된 설계는 성능에 영향을 미침
기존 프로그램 수정보다는 설계 변경이 효과적 
1.7 
       주의 사항 
 
존재하지도 않는 성능 저하 문제점을 해결하려고 시간 낭비 하지 말 것
뛰어나게 효과가 나지 않을 때는 변경 자제
관리하기 어려운 방식으로 문제 해결하지 말 것 
한번에 많은 변경을 하지 말 것 
 
 
1.8 
       벤치마크 
 
성능을 정량적으로 측정하는 방법
다음 사항을 측정하기 위한 벤치마크 설정
문제점이 실제적으로 성능 저하 요인인가 ?
변경이 성능을 향상 시키는가 ?
주관적인 측정치에 의존하지 말 것 
1.9 
       시간 측정 
 
LONG ll_start, ll_elapsed

// 시작 시간 지정

ll_start = CPU( )

// 측정할 과정 기술

...

// 경과 시간 계산

ll_elapsed = CPU( ) - 
ll_start

파워빌더 
         6.0에서는 프로파일러 이용하여 성능 측정

1.10 
       부하를 이동하거나 분산 
 
긴 작업을 작은 단위로 나눔:
모든 데이터를 조회 후 윈도우를 보여 주는 것 보다는 
윈도우를 먼저 보여 주고 데이터를 가져와서 보여 주는 게 효과적
동일하게 시간이 걸려도 사용자는 덜 지루함 
1.11 
       사용자에게 볼 것을 제공 
 
마우스 포인터 모양 변경
도움말(MicroHelp) 제공
진행과정을 측정기로 보여 줌
취소를 할 수 있게 
 
 
2 장: 
     해당 실행 모듈 호출

모듈 호출

클래스 정의 올리기

관련된 컨트롤과 메뉴 만들기

스크립트 실행

데이터 조회

  
 
2.1 
       모듈 호출 시 영향을 주는 요소 
 
클래스 정의 호출
관련된 컨트롤과 메뉴 생성
스크립트 실행
데이터 조회 
2.2 
       윈도우가 나타나는 과정 
 
클래스 풀에서 해당 모듈을 찾는다.
클래스가 풀에 없으면 라이브러리에서 찾는다. (지정된 라이브러리 순서대로)
윈도우를 생성.
각종 컨트롤을 생성.
관련된 메뉴를 만든다.
각 컨트롤의 Constructor 
       이벤트
윈도우 Open, 
       Activate, Show, Resize 이벤트
스크립트에 있는 데이터 조회 수행
데이터윈도우에 지정된 기능 수행(Sort, Filter..) 
2.3 
       클래스 정의 호출 
 
라이브러리 정비
성능 면이 아닌 관리 측면에서
한번 호출한 것은 등록되어 다시 찾지 않음
각 PBL당 PBD, EXE 모듈은 작게
관련된 모듈끼리 동일 라이브러리에
클라이언트에 파일을 설치 
성능은 향상이 되더라도
분산과 사용자 버전관리가 문제 
2.4 
       관련된 컨트롤과 메뉴 생성 
 
한 윈도우에 컨트롤의 개수를 제한 
       ( 20개)
되도록 이면 데이터윈도우 사용
윈도우 자원 적게 사용
데이터 입력 오류 검증
코드 테이블
드롭다운데이터윈도우
커스텀유저오브젝트 사용 제한
각 컨트롤 수 + 
         1
오브젝트의 크기는 성능에 영향 없음
실행 시 정의되는 인스턴스 변수는 상수로 대치 
2.5 
       재원 
 
사용되는 bmp, 
       ico 등의 PBR은 EXE에 포함 
검색 과정:
EXE - 
         PBD나 DLL - 현재 디렉토리 - 
         \Windows와 \Windows\System 디렉토리 -DOS path
원래 크기 사용
bmp, ico 만 가진 PBD, DLL ? 
2.6 
       필요 시 오브젝트 생성 
 
비즈니스 로직만 가진 유저오브젝트를 만들어 필요 시만 생성하여 사용
데이터스토어가 숨긴 데이터윈도우 컨트롤보다 좋음
OpenUserObject()을 사용하여 필요 시에만 인쇄하는 목적의 데이터스토어 생성
탭 컨트롤에는 CreateOnDemand 
       기능 사용 
2.7 
       상속 
 
상속 다단계는 문제가 되지 않음(메뉴 제외)
상속은 관리나 실행 시 이득
엔시스터의 비대와 상속 다단계는 고려 
2.8 
       클래스 풀 
 
클래스 정의는 클래스 풀에 저장
마지막 인스턴스가 종료되면 지워짐
자주 사용되는 엔시스터 정의는 클래스 풀에 상주시키는 것이 유리 
2.9 
       메뉴 
 
문제점을 분리하기 위해 메뉴를 삭제
각 메뉴 아이템은 오브젝트 하나로 제한고려
탭 컨트롤, 또 다른 윈도우
메뉴 상속은 성능에 악영향 ( 2 ~ 3 단계 ) 
2.10 
       스크립트 수행 
 
문제점을 분리하기 위해 스크립트를 코멘트화
긴 시간 수행 스크립트는 Post
오브젝트 생성시 영향을 주는 이벤트
Open 이벤트
Activate 
         이벤트
각 컨트롤의 Constructor 
         이벤트
GetFocus 
         이벤트
Show와 Resize 
         이벤트 
OpenWithParm()이나 OpenSheetWithParm()으로 윈도우 간에 데이터 교환 시 스트럭춰를 사용하기 보다는 유저오브젝트를 사용
AutoInstantiate 속성은 사용 금지 
2.11 
       메뉴 변경 
 
Hide보다는 
       Disable이 유리
ChangeMenu( ) 
       사용 금지 
2.12 
       데이터 조회 
 
먼저 윈도우를 보여 주고 데이터 조회
조건상 반드시 윈도우와 데이터를 동시에 보여 줄 경우에는 Retrieve As Needed 속성을 지정하고
Open 이벤트에서 Post 
       된 이벤트에 다음과 같은 스크립트를 지정
dw_1.Modify ( 
       ‘DataWindow.Retrieve.asneeded=no’ )
한 화면의 데이터만 필요 하다면
Retrieve As Needed 
       속성을 지정하고
Open 이벤트에서 Post 
       된 이벤트에 다음과 같은 스크립트를 지정
dw_1.DBCancel( 
       )
그 후에 적당하게 Retrieve() 
       함수를 수행 
2.13 Open 
       이벤트는 데이터 조회 삼가 
 
일반적으로 많이 사용되어지는 DDDW는 미리 조회하여 
       ShareData() 함수를 사용하여 공유
사용자가 요청 시에만 데이터 조회를 수행하는 것도 고려 
3 장: 
     스크립트 수행
 
머쉰 코드로 컴파일 

화면 재생성

데이터윈도우 관련 스크립트

루프와 배열

변수

함수와 이벤트

고려할 그 외 사항

  
 
3.1 
       머쉰 코드로 컴파일 
 
장점
변수 참조
수학적 계산이나 할당
로직을 전개하기위한 IF, CHOOSE, FOR, 
         DO 등의 문장 
함수 호출
스크립트에 관련된 사항만 향상
제한 사항
해당 모듈 호출
데이터윈도우 성능
데이터 조회
파워스크립트 함수
예: 
       Retrieve( ) 
함수는 빠르게 호출 되나
서버나 네트웍에는 영향을 미치지 못함 
3.2 
       머쉰코드와 데이터윈도우 기능 
 
파워빌더 5.0과 6.0에서는 다른 문제 해결 방법
데이터윈도우의 “.” 표기
파워빌더 4.0
For 
         ...
li_empid[ll_row] = 
           dw_1.getitemnumber

(ll_row,’emp_id’) 

파워빌더 
       5.0과 6.0
li_empid = 
         dw_1.object.emp_id.current 
3.3 
       화면 재생성 
 
화면 재생성: SetRedraw( ) 
       사용
w_main.SetRedraw(FALSE)
sle_name.Text = 
           ""

sle_address.Show( 
           )

p_photo.PictureName = "photo.bmp"

...

w_main.Title = 
           "Employee Data"

w_main.SetRedraw(TRUE) 
 
3.4 
       단수 속성 참조 
 
Describe( ) 함수
rc = 
         dw_1.describe(“dept_id.x”)
직접 속성 지정
rc = 
         dw_1.object.dept_id.x 
3.5 
       복수 속성 참조(빠른 순서) 
 
복합 
       Describe( ) 함수
modstring = 
         “dept_id.X dept_id.Y” + &
" dept_id.height 
           dept_id.width"

rc=dw_1.Describe( 
           modstring ) 

각각의 
       Describe( ) 함수
각각의 직접 속성 지정
li_x = 
         dw_1.Object.dept_id.X 
3.6 
       단수 속성 지정 
 
Modify( ) 함수
dw_1.Modify( 
         “customer_name.Font.Italic=1”)
직접 속성 지정
dw_1.Object.customer_name.Font.Italic=1 
3.7 
       복수 속성 지정(빠른 순서) 
 
복합 Modify( 
       ) 함수
ls_modstring= 
         "customer_name.Font.Italic=1~t 
customer_city.Color=255"
dw_1.Modify( 
         ls_modstring )
복합 Modify( 
       ) 함수는 SetRedraw( ) 
       사용
직접 속성 지정 시에도 SetRedraw( ) 사용 
3.8 
       데이터 조회 
 
GetItemx( )
ll_id = 
         dw_1.GetItemNumber(1, "emp_id")
직접 참조
ll_id=dw_1.Object.emp_id [1]
GetItemx( ) 가 빠르다.
직접 참조는 블럭 단위 조회 시 유리
예: 
       컬럼 복사
기존 4.0 
         방식: 

string ls_array[ 
         ]
long ll_numrows, 
           i

ll_numrows = 
           dw_1.rowcount ( )

FOR i = ll_numrows 
           to 1 step -1

ls_array [i] = 
           dw_1.GetItemString(i, "emp_name" )

NEXT

5.0과 6.0 방식: 

string ls_array[ 
         ]
ls_array = 
           dw_1.Object.emp_name.Current 
 
3.9 
       데이터 변경 
 
SetItem( )
dw_1.SetItem( 1, 
         "emp_id", ll_id )
직접 변경
dw_1.Object.emp_id 
         [1] = ll_id
SetItem( ) 이 빠르다.
직접 변경은 블럭 단위가 유리. 
3.10 
       데이터윈도우 간의 데이터 공유 
 
반복적으로 조회 불필요
메모리 상에서 데이터 복사는 되도록 회피 
3.11 
       데이터윈도우 간의 데이터 복사 
 
RowsCopy( )
직접 지정
dw_1.Object.Data = 
         dw_2.Object.Data
ImportClipboard( )
ImportString( )
GetItemx( ) / SetItem( ) 
       loop 
3.12 
       선택된 로우만 복사 
 
dw_2.Object.Data = 
       dw_1.Object.Data.Selected
GetSelectedRow( ) 와 RowsCopy( )보다 유리 
3.13 
       데이터윈도우 이벤트 
 
RetrieveRow 이벤트
이벤트 아규먼트 사용
ItemChanged 
         이벤트에서 GetRow() 대신에 Row사용
ItemChanged, EditChanged, 
       ItemFocusChanged, pbm_dwnkey, RowFocusChanged 이벤트에는 되도록 가볍게 작성 
3.14 
       컬럼 이름과 컬럼 번호 
 
컬럼 이름이 관리상 유리
GetItemx( )과 SetItem( )일 경우에는 번호가 조금 빠르고
직접 지정 일 경우에는 번호가 현격하게 빠르다. 
3.15 
       테이블 간의 데이터 이동 
 
데이터파이프라인 사용하는 방법과 데이터윈도우를 중간에 개입하는 방법
데이터파이프라인이 현격하게 빠르다. 
3.16 
       루프와 배열 
 
배열 초기화
intoriginalarray[ 
         ]
intdummyarray[ 
           ]

originalarray = 
           dummyarray 

함수에서 배열을 교환 할 경우에는 Pass by 
       reference나 Read Only 사용
루프내에서 동일한 값을 리턴하는 함수 사용금지
되도록 루프 내에는 작게 작성
이 방식 보다는:
FOR li_index = 1 
         TO UpperBound(li_array)
... 

이방식이 유리:
int 
         li_array_len
li_array_len = 
           UpperBound(li_array)

FOR li_index = 1 
           TO li_array_len

...
 
3.17 
       동적 배열 
 
동적 배열을 사용 할 경우에는 반대로
FOR li_index = 1 
         to li_max
li_array[li_index] 
           = li_index * 10

NEXT 

FOR li_index = 
         li_max to 1 STEP -1
li_array[li_index] 
           = li_index * 10

NEXT 

정적 배열이 동적 배열보다 유리 
3.18 
       변수 
 
참조 시간
Global[t] = 
         Shared[t] 나 Instance[t] * 2
Global[t] = 
         Local[t] * 3
변수 지정 영역
동일 이벤트나 함수 내에서 변수 선언 장소는 문제되지 않음
상수는 개발 시 변수는 실행 시 지정
Any 데이터 타입은 사용 자제 
3.19 
       함수 
 
파워빌더에서 이미 제공하는 함수는 만들지 말 것
해당 오브젝트에 포함되는 함수가 광역 함수보다 유리
지정과 미지정은 동일
wf_save()
Parent.wf_save() 
3.20 
       이벤트와 함수 
 
먼저 성능과는 무관하게 이벤트로 할지 함수로 할지를 결정
4.0과 달리 
       5.0과 6.0에서는 이벤트와 함수가 유사
차이점으로는
이벤트는 오브젝트과만 연관됨
정의되지 않은 함수는 에러 발생
함수는 영역 지정 가능
함수는 찾는 과정이 복잡(외부->광역->오브젝트->앤시스터)
성능 비교(속도가 빠른 순위)
정적 이벤트와 정적 함수
TriggerEvent( ) 
         함수
동적 함수
동적 이벤트 
3.21 
       고려할 그 외 사항 
 
단축 지정 문장이 유리
++, 
         ---
코멘트 삭제
RetrieveRow 
         이벤트에는 되도록 삭제
이벤트
자주 발생하는 이벤트에는 되도록 짧게 작성(MouseMove, 
         Other...)
CHOOSE 
       CASE가 IF / ELSEIF보다 관리면에서 유리
오브젝트 참조 변수
ParentWindow( ) 
         함수를 계속 사용하기 보다는 변수 선언이 유리 
4 장: 
     데이터 조회
 
일반 사항

데이터베이스 설계

SQL 
       튜닝

결과치 감소

데이터 케싱

클라이언트와 서버에 분할

데이터윈도우 오브젝트 실행

  
 
4.1 
       일반 사항 
 
언제 데이터가 필요 한가 
?
반드시 모든 데이터가 필요 한가 
?
결과치를 줄일 수 있는가 ?
설계는 맞는가 ?
데이터베이스 관리자가 관여 하였는가 
       ! 
4.2 
       데이터베이스 연결 최소화 
 
Connect;와 
       DisConnect;를 적절히
SetTrans( 
       )보다는 SetTransObject( ) 사용 
4.3 
       역정규화 
 
정규화 된 데이터베이스는 복잡한 조인을 요구
조인을 줄이기 위하여 역정규화
요약 정보 테이블 생성이 필요 
4.4 
       트랜잭션 관리 
 
COMMIT과 
       ROLLBACK을 적절히 사용하여 서버에서 잡고 있는 자원을 풀어 줌
Retrieve()만 한 경우도 서버의 자원을 잡고 있을 수 있음 
4.5 SQL 
       문장 케싱 
 
반복적인 SQL 문장 
DBParm 속성: Oracle, 
       ODBC
SQLCache=<케쉬하고자 하는 문장 개수>
SQLCache=0 
       케쉬 취소
SQLReturnData를 사용하여 크기 결정
연결 종료 시 케쉬 정보가 들어옴 
4.6 
       바인드 기능 
 
동일한 SQL 문장이고 데이터 값 만 변경이 일어날 경우 한번만 컴파일
DBParm 속성
가 능: DisableBind=1
불가능: 
DisableBind=0
SQLPreview 
       이벤트에서 확인
바인드 적용:
UPDATE department 
         SET dept_name = ?, dept_head_id = ? WHERE dept_id = 
       ?
바인드 비적용:
UPDATE department 
         SET dept_name = ‘Sales’,dept_head_id = 35 
WHERE dept_id = 
         300 
 
 
4.7 
       문제점 분리 
 
SQL 질의를 두 군데에서 
데이터베이스 관리자 페인터
데이터윈도우 페인터
성능이 만족되는가 ?
예: 데이터윈도우 컨트롤의 스크립트를 점검
아니오: SQL 문장 자체를 점검 
4.8 SQL 
       문장은 단순하게 
 
WHERE 절의 
       LIKE를 사용 절제
복잡한 질의를 단순하게 분리
조인은 되도록 삼가 
4.9 
       조인 대신에 DDDW 
       사용 
 
DDDW를 과다하게 사용하면 성능 저하
항상 DDDW가 조인보다 빠른 것이 아님 
4.10 
       데이터윈도우의 변경 속성 조정 
 
WHERE 절이 성능에 지대한 영향
성능이 아닌 동시성과 지속성에 중점 
4.11 
       그 외 SQL 
       관련 사항 
 
스크립트 내에 SQL을 삽입하기 보다는 데이터윈도우나 데이터스토어를 사용
RPC나 스토어드프로시줘를 사용
Explain SQL 
       기능을 이용하여 SQL 질의를 최적화 
 
 
4.12 
       결과치 감소 
 
필요한 데이터만 조회
SELECT * FROM 
         TABLE 금지
조회 취소
결과치 최소화
보고서가 아닌 온라인 조회일 경우 100 건 이상은 현실성 부족
필요한 컬럼을 미리 조회
데이터기 변경이 없다면 데이터윈도우 오브젝트를 데이터와 함께 저장 
4.13 
       하드디스크에 데이터 저장 
 
Rows->Retireve->Rows to Disk 
4.14 
       클라이언트와 서버에 분할 
 
정열
필터링
통계나 계산 
그룹핑
데이터 확인 
4.15 
       데이터윈도우 수행 
 
데이터윈도우는 별도의 엔진을 사용하므로 머쉰코드로 만들더라도 별 효과 없음
데이터윈도우에 지정된 모든 기능은 별도의 데이터윈도우 엔진이 모두 담당
계산 필드, 데이터 확인, 포맷, 정열, 필터 
4.16 
       계산 필드 
 
각 로우 별로 조회 후 계산되므로 성능 저하 요인이 되므로 되도록 계산 컬럼을 사용하는 게 유리 
4.17 
       디스플레이시 영향을 주는 것 
 
슬라이드 컬럼
AutoHeight 
       컬럼
bmp 참조 시
EXE에 포함시키거나
폰트를 활용(Wingding...)
그래프로 데이터표현 시 레이블을 회전시키지는 말 것 
4.18 
       내부 기능 
 
네스티드 데이터윈도우 사용 시에는 케쉬나 바인드 기능을 사용
5.0과 
       6.0에서는 데이터윈도우에 새로운 데이터 형식이 있으므로 해당 형식에 맞게 지정
int
long
real 
4.19 
       조회 전 데이터윈도우와 테이블 비교 
 
파워빌더는 조회 전 데이터윈도우에 정의된 정보와 테이블의 내용이 일치하는지 미리 조사 한 후 조회
DBParm 속성 지정
결과치 비교 조사 취소: 

SQLCA.DBParm = 
         'StaticBind=1'
 

결과치 비교 조사 : 
         

SQLCA.DBParm = 
         'StaticBind=0' 
5 장: 
     그 외 사항
 
애플리케이션 성능 저하

애플리케이션 여는 시간

포커스 이동

DDDW가 늦게 열림

윈도우 활성

라이브러리 관리

시스템 구성

  
 
5.1 
       애플리케이션 성능 저하 
 
열었으면 닫아야 함
생성했으면 제거도 하여야 함
OpenUserObject( 
       )을 사용하였으면 CloseUserObject( )도 기술
OpenTab( ) 
       을 사용하였으면 CloseTab( ) 도 기술
연결하였으면 연결 종료도 하여야 함 
5.2 
       변수 선언 없이 생성 
 
변수 선언 없이 유저오브젝트를 생성하지 말 것
n_trans = CREATE 
         n_trans
문장 상으로 문제는 없으나 계속적으로 필요 없는 것이 생성됨 
5.3 
       애플리케이션 열기 
 
애플리케이션 시작 시에 다음에 필요한 작업을 하는 것도 고려 해 볼만 함
데이터베이스 연결 및 초기화
코드 테이블 조회
보안
만약에 애플리케이션 여는 시간이 문제라면 메인 윈도우에서 처리 
 
 
5.4 
       데이터윈도우 컬럼 간 이동 
 
ItemChanged 
       이벤트
ItemFocusChanged 
       이벤트
RowFocusChanged 
       이벤트
데이터 검증 룰
계산 필드
조건부 수행 
5.5 
       컨트롤 간 이동 
 
LoseFocus 
       이벤트
GetFocus 
       이벤트 
5.6 
       포커스 이동 시 문제점 해결 
 
중요하지 않은 과정은 Post
스크립트 수정
데이터 조회 시점 변경
데이터윈도우 오브젝트 점검
앤시스터 스크립트 확인 
5.7 
       DDDW가 늦게 열림 
 
각 DDDW가 각각 조회하는 것보다는 공유
pbm_dwndropdown 
       이벤트 점검 
5.8 
       윈도우 활성 
 
윈도우 활성이 늦으면 Activate, DeActivate 이벤트를 점검
시간이 걸리는 데이터조회는 
         Post
Activate 
         이벤트에 메뉴 관련 로직은 삼가
쉬트를 관리하기 위한 로직이 Activate 이벤트에 있다면 GetFirstSheet( ), 
         GetNextSheet( ), GetActivateSheet() 함수로 대치하여 전개 
5.9 
       라이브러리 관리 
 
대규모 애플리케이션인 경우 
       SetLibraryList( ) 함수를 이용하여 라이브러리 찾는 순서를 변경하는 것도 고려
앤시스터 오브젝트가 있는 라이브러리는 처음으로
하위시스템으로 전환시
사용자에 따라 사용하는 부분이 다를 경우 
5.10 
       오브젝트 재생성 
 
구조상 변화 시 재생성
추가나 삭제:
인스턴스나 쉐어드 변수
오브젝트 함수
이벤트 전부
윈도우나 유저오브젝트의 컨트롤
메뉴 오브젝트의 메뉴 아이템
사용자 정의 이벤트 선언이나 삭제 
5.11 
       라이브러리 최적화 
 
한 라이브러리 오브젝트 개수는 
       50 ~ 60 개
한 라이브러리의 크기는 800 
       K
PBL의 조각난 부분을 최적화 하면
개발 시 실행이 빠름
하드디스크 공간을 작게 사용
재생성 후 최적화 
5.12 
       시스템 구성 
 
연장 메모리 사용
메모리 추가
디스크 케싱 사용
배경 그림 비사용 
낮은 해상도 사용
DOS 환경 파일 숙지
CONFIG.SYS
AUTOEXEC.BAT
영구 스왑 파일 사용
스왑 파일을 네트웍 상에 두지는 말 것
하드디스크 조각 모음을 정기적으로
하드드라이브의 속도와 디스크 분할 확인
Windows 
       3.1일 경우 SmartDrive 사용
Windows 환경 파일 숙지
WIN.INI 
         
SYSTEM.INI
되도록 이면 큰 메모리 사용
Windows 3.1: 
         16M
Windows 95 : 32M 
         
개발 시 사용자 환경을 고려
사용자 환경에서 테스트
서버 용량 증대
파워빌더 실행 모듈이 있는 디렉토리는 Path제일 처음 위치로 
읽어보시면 상당히 유용한 내용입니다.

파워빌더 성능 관리
 
근래에 파워빌더로 개발된 곳에서 성능 측정을 요구하는 곳이 많아 지원을 가보면 
일반적으로 고려하여야 할 사항을 무시하고 개발된 곳이 대부분이라 성능이 문제가 되고 있었다.

파워빌더의 문제라기보다는 파워빌더에 맞는 고려사항을 인지하지 못한 탓이다. 
이런 이유로 고객의 요구에 의해 본사에서 시행하는 성능관리 교육교재를 요약하여 싣는다.

(Managing Performance in 
     PowerBuilder)
 
목차 
 
1 장: 
     개요

2 장: 
     해당 실행 모듈 호출

3 장: 
     스크립트 실행 

4 장: 
     데이터 조회

5 장: 
     그 외 사항 
 
1 장: 
     개요
 
성능 이란 
       ?

성능과 관련된 문제점과 토론 사항

성능 향상 정책 수립

사용자 인식 관리

  
 
1.1 
       성능이란 ? 
 
사용자 관점의 성능
성능이라는 것은 실행 시 얼마나 빨리 시스템이 응답하느냐는 것이다. 

개발자 관점의 성능
성능은 다음과 같은 사항을 고려 

서버의 부하
네트웍의 거리
사용자 수
클라이언트와 서버의 구성
데이터베이스 설계와 정규화
애플리케이션의 설계와 작성
사용자의 인지도 
1.2 
       일반적인 성능 불만 사항 
 
윈도우를 열 때 
데이터 조회 시 
애플리케이션 실행 시
필드간 이동 시 
윈도우 간 이동 시
계속하여 실행 시
 
 
1.3 
       문제 발생 요인 
 
해당 실행 모듈 호출
스크립트 실행
데이터 조회
하드웨어와 소프트웨어 구성 
1.4 
       성능 향상 정책 수립 
 
문제점 분리
문제점 범위 지정
이벤트
함수
과정
기능
모든 것이 느리다는 것은 용인되지 않음 
 
 
1.5 
       애플리케이션 환경 점검 
 
애플리케이션의 문제인지 구성 문제인지 ? 
보다 더 성능이 뛰어난 기계에서 실행
관련 모듈을 클라이언트에 설치 
 
 
 
 
1.6 
       설계 재점검 
 
잘못된 설계는 성능에 영향을 미침
기존 프로그램 수정보다는 설계 변경이 효과적 
1.7 
       주의 사항 
 
존재하지도 않는 성능 저하 문제점을 해결하려고 시간 낭비 하지 말 것
뛰어나게 효과가 나지 않을 때는 변경 자제
관리하기 어려운 방식으로 문제 해결하지 말 것 
한번에 많은 변경을 하지 말 것 
 
 
1.8 
       벤치마크 
 
성능을 정량적으로 측정하는 방법
다음 사항을 측정하기 위한 벤치마크 설정
문제점이 실제적으로 성능 저하 요인인가 ?
변경이 성능을 향상 시키는가 ?
주관적인 측정치에 의존하지 말 것 
1.9 
       시간 측정 
 
LONG ll_start, ll_elapsed

// 시작 시간 지정

ll_start = CPU( )

// 측정할 과정 기술

...

// 경과 시간 계산

ll_elapsed = CPU( ) - 
ll_start

파워빌더 
         6.0에서는 프로파일러 이용하여 성능 측정

1.10 
       부하를 이동하거나 분산 
 
긴 작업을 작은 단위로 나눔:
모든 데이터를 조회 후 윈도우를 보여 주는 것 보다는 
윈도우를 먼저 보여 주고 데이터를 가져와서 보여 주는 게 효과적
동일하게 시간이 걸려도 사용자는 덜 지루함 
1.11 
       사용자에게 볼 것을 제공 
 
마우스 포인터 모양 변경
도움말(MicroHelp) 제공
진행과정을 측정기로 보여 줌
취소를 할 수 있게 
 
 
2 장: 
     해당 실행 모듈 호출

모듈 호출

클래스 정의 올리기

관련된 컨트롤과 메뉴 만들기

스크립트 실행

데이터 조회

  
 
2.1 
       모듈 호출 시 영향을 주는 요소 
 
클래스 정의 호출
관련된 컨트롤과 메뉴 생성
스크립트 실행
데이터 조회 
2.2 
       윈도우가 나타나는 과정 
 
클래스 풀에서 해당 모듈을 찾는다.
클래스가 풀에 없으면 라이브러리에서 찾는다. (지정된 라이브러리 순서대로)
윈도우를 생성.
각종 컨트롤을 생성.
관련된 메뉴를 만든다.
각 컨트롤의 Constructor 
       이벤트
윈도우 Open, 
       Activate, Show, Resize 이벤트
스크립트에 있는 데이터 조회 수행
데이터윈도우에 지정된 기능 수행(Sort, Filter..) 
2.3 
       클래스 정의 호출 
 
라이브러리 정비
성능 면이 아닌 관리 측면에서
한번 호출한 것은 등록되어 다시 찾지 않음
각 PBL당 PBD, EXE 모듈은 작게
관련된 모듈끼리 동일 라이브러리에
클라이언트에 파일을 설치 
성능은 향상이 되더라도
분산과 사용자 버전관리가 문제 
2.4 
       관련된 컨트롤과 메뉴 생성 
 
한 윈도우에 컨트롤의 개수를 제한 
       ( 20개)
되도록 이면 데이터윈도우 사용
윈도우 자원 적게 사용
데이터 입력 오류 검증
코드 테이블
드롭다운데이터윈도우
커스텀유저오브젝트 사용 제한
각 컨트롤 수 + 
         1
오브젝트의 크기는 성능에 영향 없음
실행 시 정의되는 인스턴스 변수는 상수로 대치 
2.5 
       재원 
 
사용되는 bmp, 
       ico 등의 PBR은 EXE에 포함 
검색 과정:
EXE - 
         PBD나 DLL - 현재 디렉토리 - 
         \Windows와 \Windows\System 디렉토리 -DOS path
원래 크기 사용
bmp, ico 만 가진 PBD, DLL ? 
2.6 
       필요 시 오브젝트 생성 
 
비즈니스 로직만 가진 유저오브젝트를 만들어 필요 시만 생성하여 사용
데이터스토어가 숨긴 데이터윈도우 컨트롤보다 좋음
OpenUserObject()을 사용하여 필요 시에만 인쇄하는 목적의 데이터스토어 생성
탭 컨트롤에는 CreateOnDemand 
       기능 사용 
2.7 
       상속 
 
상속 다단계는 문제가 되지 않음(메뉴 제외)
상속은 관리나 실행 시 이득
엔시스터의 비대와 상속 다단계는 고려 
2.8 
       클래스 풀 
 
클래스 정의는 클래스 풀에 저장
마지막 인스턴스가 종료되면 지워짐
자주 사용되는 엔시스터 정의는 클래스 풀에 상주시키는 것이 유리 
2.9 
       메뉴 
 
문제점을 분리하기 위해 메뉴를 삭제
각 메뉴 아이템은 오브젝트 하나로 제한고려
탭 컨트롤, 또 다른 윈도우
메뉴 상속은 성능에 악영향 ( 2 ~ 3 단계 ) 
2.10 
       스크립트 수행 
 
문제점을 분리하기 위해 스크립트를 코멘트화
긴 시간 수행 스크립트는 Post
오브젝트 생성시 영향을 주는 이벤트
Open 이벤트
Activate 
         이벤트
각 컨트롤의 Constructor 
         이벤트
GetFocus 
         이벤트
Show와 Resize 
         이벤트 
OpenWithParm()이나 OpenSheetWithParm()으로 윈도우 간에 데이터 교환 시 스트럭춰를 사용하기 보다는 유저오브젝트를 사용
AutoInstantiate 속성은 사용 금지 
2.11 
       메뉴 변경 
 
Hide보다는 
       Disable이 유리
ChangeMenu( ) 
       사용 금지 
2.12 
       데이터 조회 
 
먼저 윈도우를 보여 주고 데이터 조회
조건상 반드시 윈도우와 데이터를 동시에 보여 줄 경우에는 Retrieve As Needed 속성을 지정하고
Open 이벤트에서 Post 
       된 이벤트에 다음과 같은 스크립트를 지정
dw_1.Modify ( 
       ‘DataWindow.Retrieve.asneeded=no’ )
한 화면의 데이터만 필요 하다면
Retrieve As Needed 
       속성을 지정하고
Open 이벤트에서 Post 
       된 이벤트에 다음과 같은 스크립트를 지정
dw_1.DBCancel( 
       )
그 후에 적당하게 Retrieve() 
       함수를 수행 
2.13 Open 
       이벤트는 데이터 조회 삼가 
 
일반적으로 많이 사용되어지는 DDDW는 미리 조회하여 
       ShareData() 함수를 사용하여 공유
사용자가 요청 시에만 데이터 조회를 수행하는 것도 고려 
3 장: 
     스크립트 수행
 
머쉰 코드로 컴파일 

화면 재생성

데이터윈도우 관련 스크립트

루프와 배열

변수

함수와 이벤트

고려할 그 외 사항

  
 
3.1 
       머쉰 코드로 컴파일 
 
장점
변수 참조
수학적 계산이나 할당
로직을 전개하기위한 IF, CHOOSE, FOR, 
         DO 등의 문장 
함수 호출
스크립트에 관련된 사항만 향상
제한 사항
해당 모듈 호출
데이터윈도우 성능
데이터 조회
파워스크립트 함수
예: 
       Retrieve( ) 
함수는 빠르게 호출 되나
서버나 네트웍에는 영향을 미치지 못함 
3.2 
       머쉰코드와 데이터윈도우 기능 
 
파워빌더 5.0과 6.0에서는 다른 문제 해결 방법
데이터윈도우의 “.” 표기
파워빌더 4.0
For 
         ...
li_empid[ll_row] = 
           dw_1.getitemnumber

(ll_row,’emp_id’) 

파워빌더 
       5.0과 6.0
li_empid = 
         dw_1.object.emp_id.current 
3.3 
       화면 재생성 
 
화면 재생성: SetRedraw( ) 
       사용
w_main.SetRedraw(FALSE)
sle_name.Text = 
           ""

sle_address.Show( 
           )

p_photo.PictureName = "photo.bmp"

...

w_main.Title = 
           "Employee Data"

w_main.SetRedraw(TRUE) 
 
3.4 
       단수 속성 참조 
 
Describe( ) 함수
rc = 
         dw_1.describe(“dept_id.x”)
직접 속성 지정
rc = 
         dw_1.object.dept_id.x 
3.5 
       복수 속성 참조(빠른 순서) 
 
복합 
       Describe( ) 함수
modstring = 
         “dept_id.X dept_id.Y” + &
" dept_id.height 
           dept_id.width"

rc=dw_1.Describe( 
           modstring ) 

각각의 
       Describe( ) 함수
각각의 직접 속성 지정
li_x = 
         dw_1.Object.dept_id.X 
3.6 
       단수 속성 지정 
 
Modify( ) 함수
dw_1.Modify( 
         “customer_name.Font.Italic=1”)
직접 속성 지정
dw_1.Object.customer_name.Font.Italic=1 
3.7 
       복수 속성 지정(빠른 순서) 
 
복합 Modify( 
       ) 함수
ls_modstring= 
         "customer_name.Font.Italic=1~t 
customer_city.Color=255"
dw_1.Modify( 
         ls_modstring )
복합 Modify( 
       ) 함수는 SetRedraw( ) 
       사용
직접 속성 지정 시에도 SetRedraw( ) 사용 
3.8 
       데이터 조회 
 
GetItemx( )
ll_id = 
         dw_1.GetItemNumber(1, "emp_id")
직접 참조
ll_id=dw_1.Object.emp_id [1]
GetItemx( ) 가 빠르다.
직접 참조는 블럭 단위 조회 시 유리
예: 
       컬럼 복사
기존 4.0 
         방식: 

string ls_array[ 
         ]
long ll_numrows, 
           i

ll_numrows = 
           dw_1.rowcount ( )

FOR i = ll_numrows 
           to 1 step -1

ls_array [i] = 
           dw_1.GetItemString(i, "emp_name" )

NEXT

5.0과 6.0 방식: 

string ls_array[ 
         ]
ls_array = 
           dw_1.Object.emp_name.Current 
 
3.9 
       데이터 변경 
 
SetItem( )
dw_1.SetItem( 1, 
         "emp_id", ll_id )
직접 변경
dw_1.Object.emp_id 
         [1] = ll_id
SetItem( ) 이 빠르다.
직접 변경은 블럭 단위가 유리. 
3.10 
       데이터윈도우 간의 데이터 공유 
 
반복적으로 조회 불필요
메모리 상에서 데이터 복사는 되도록 회피 
3.11 
       데이터윈도우 간의 데이터 복사 
 
RowsCopy( )
직접 지정
dw_1.Object.Data = 
         dw_2.Object.Data
ImportClipboard( )
ImportString( )
GetItemx( ) / SetItem( ) 
       loop 
3.12 
       선택된 로우만 복사 
 
dw_2.Object.Data = 
       dw_1.Object.Data.Selected
GetSelectedRow( ) 와 RowsCopy( )보다 유리 
3.13 
       데이터윈도우 이벤트 
 
RetrieveRow 이벤트
이벤트 아규먼트 사용
ItemChanged 
         이벤트에서 GetRow() 대신에 Row사용
ItemChanged, EditChanged, 
       ItemFocusChanged, pbm_dwnkey, RowFocusChanged 이벤트에는 되도록 가볍게 작성 
3.14 
       컬럼 이름과 컬럼 번호 
 
컬럼 이름이 관리상 유리
GetItemx( )과 SetItem( )일 경우에는 번호가 조금 빠르고
직접 지정 일 경우에는 번호가 현격하게 빠르다. 
3.15 
       테이블 간의 데이터 이동 
 
데이터파이프라인 사용하는 방법과 데이터윈도우를 중간에 개입하는 방법
데이터파이프라인이 현격하게 빠르다. 
3.16 
       루프와 배열 
 
배열 초기화
intoriginalarray[ 
         ]
intdummyarray[ 
           ]

originalarray = 
           dummyarray 

함수에서 배열을 교환 할 경우에는 Pass by 
       reference나 Read Only 사용
루프내에서 동일한 값을 리턴하는 함수 사용금지
되도록 루프 내에는 작게 작성
이 방식 보다는:
FOR li_index = 1 
         TO UpperBound(li_array)
... 

이방식이 유리:
int 
         li_array_len
li_array_len = 
           UpperBound(li_array)

FOR li_index = 1 
           TO li_array_len

...
 
3.17 
       동적 배열 
 
동적 배열을 사용 할 경우에는 반대로
FOR li_index = 1 
         to li_max
li_array[li_index] 
           = li_index * 10

NEXT 

FOR li_index = 
         li_max to 1 STEP -1
li_array[li_index] 
           = li_index * 10

NEXT 

정적 배열이 동적 배열보다 유리 
3.18 
       변수 
 
참조 시간
Global[t] = 
         Shared[t] 나 Instance[t] * 2
Global[t] = 
         Local[t] * 3
변수 지정 영역
동일 이벤트나 함수 내에서 변수 선언 장소는 문제되지 않음
상수는 개발 시 변수는 실행 시 지정
Any 데이터 타입은 사용 자제 
3.19 
       함수 
 
파워빌더에서 이미 제공하는 함수는 만들지 말 것
해당 오브젝트에 포함되는 함수가 광역 함수보다 유리
지정과 미지정은 동일
wf_save()
Parent.wf_save() 
3.20 
       이벤트와 함수 
 
먼저 성능과는 무관하게 이벤트로 할지 함수로 할지를 결정
4.0과 달리 
       5.0과 6.0에서는 이벤트와 함수가 유사
차이점으로는
이벤트는 오브젝트과만 연관됨
정의되지 않은 함수는 에러 발생
함수는 영역 지정 가능
함수는 찾는 과정이 복잡(외부->광역->오브젝트->앤시스터)
성능 비교(속도가 빠른 순위)
정적 이벤트와 정적 함수
TriggerEvent( ) 
         함수
동적 함수
동적 이벤트 
3.21 
       고려할 그 외 사항 
 
단축 지정 문장이 유리
++, 
         ---
코멘트 삭제
RetrieveRow 
         이벤트에는 되도록 삭제
이벤트
자주 발생하는 이벤트에는 되도록 짧게 작성(MouseMove, 
         Other...)
CHOOSE 
       CASE가 IF / ELSEIF보다 관리면에서 유리
오브젝트 참조 변수
ParentWindow( ) 
         함수를 계속 사용하기 보다는 변수 선언이 유리 
4 장: 
     데이터 조회
 
일반 사항

데이터베이스 설계

SQL 
       튜닝

결과치 감소

데이터 케싱

클라이언트와 서버에 분할

데이터윈도우 오브젝트 실행

  
 
4.1 
       일반 사항 
 
언제 데이터가 필요 한가 
?
반드시 모든 데이터가 필요 한가 
?
결과치를 줄일 수 있는가 ?
설계는 맞는가 ?
데이터베이스 관리자가 관여 하였는가 
       ! 
4.2 
       데이터베이스 연결 최소화 
 
Connect;와 
       DisConnect;를 적절히
SetTrans( 
       )보다는 SetTransObject( ) 사용 
4.3 
       역정규화 
 
정규화 된 데이터베이스는 복잡한 조인을 요구
조인을 줄이기 위하여 역정규화
요약 정보 테이블 생성이 필요 
4.4 
       트랜잭션 관리 
 
COMMIT과 
       ROLLBACK을 적절히 사용하여 서버에서 잡고 있는 자원을 풀어 줌
Retrieve()만 한 경우도 서버의 자원을 잡고 있을 수 있음 
4.5 SQL 
       문장 케싱 
 
반복적인 SQL 문장 
DBParm 속성: Oracle, 
       ODBC
SQLCache=<케쉬하고자 하는 문장 개수>
SQLCache=0 
       케쉬 취소
SQLReturnData를 사용하여 크기 결정
연결 종료 시 케쉬 정보가 들어옴 
4.6 
       바인드 기능 
 
동일한 SQL 문장이고 데이터 값 만 변경이 일어날 경우 한번만 컴파일
DBParm 속성
가 능: DisableBind=1
불가능: 
DisableBind=0
SQLPreview 
       이벤트에서 확인
바인드 적용:
UPDATE department 
         SET dept_name = ?, dept_head_id = ? WHERE dept_id = 
       ?
바인드 비적용:
UPDATE department 
         SET dept_name = ‘Sales’,dept_head_id = 35 
WHERE dept_id = 
         300 
 
 
4.7 
       문제점 분리 
 
SQL 질의를 두 군데에서 
데이터베이스 관리자 페인터
데이터윈도우 페인터
성능이 만족되는가 ?
예: 데이터윈도우 컨트롤의 스크립트를 점검
아니오: SQL 문장 자체를 점검 
4.8 SQL 
       문장은 단순하게 
 
WHERE 절의 
       LIKE를 사용 절제
복잡한 질의를 단순하게 분리
조인은 되도록 삼가 
4.9 
       조인 대신에 DDDW 
       사용 
 
DDDW를 과다하게 사용하면 성능 저하
항상 DDDW가 조인보다 빠른 것이 아님 
4.10 
       데이터윈도우의 변경 속성 조정 
 
WHERE 절이 성능에 지대한 영향
성능이 아닌 동시성과 지속성에 중점 
4.11 
       그 외 SQL 
       관련 사항 
 
스크립트 내에 SQL을 삽입하기 보다는 데이터윈도우나 데이터스토어를 사용
RPC나 스토어드프로시줘를 사용
Explain SQL 
       기능을 이용하여 SQL 질의를 최적화 
 
 
4.12 
       결과치 감소 
 
필요한 데이터만 조회
SELECT * FROM 
         TABLE 금지
조회 취소
결과치 최소화
보고서가 아닌 온라인 조회일 경우 100 건 이상은 현실성 부족
필요한 컬럼을 미리 조회
데이터기 변경이 없다면 데이터윈도우 오브젝트를 데이터와 함께 저장 
4.13 
       하드디스크에 데이터 저장 
 
Rows->Retireve->Rows to Disk 
4.14 
       클라이언트와 서버에 분할 
 
정열
필터링
통계나 계산 
그룹핑
데이터 확인 
4.15 
       데이터윈도우 수행 
 
데이터윈도우는 별도의 엔진을 사용하므로 머쉰코드로 만들더라도 별 효과 없음
데이터윈도우에 지정된 모든 기능은 별도의 데이터윈도우 엔진이 모두 담당
계산 필드, 데이터 확인, 포맷, 정열, 필터 
4.16 
       계산 필드 
 
각 로우 별로 조회 후 계산되므로 성능 저하 요인이 되므로 되도록 계산 컬럼을 사용하는 게 유리 
4.17 
       디스플레이시 영향을 주는 것 
 
슬라이드 컬럼
AutoHeight 
       컬럼
bmp 참조 시
EXE에 포함시키거나
폰트를 활용(Wingding...)
그래프로 데이터표현 시 레이블을 회전시키지는 말 것 
4.18 
       내부 기능 
 
네스티드 데이터윈도우 사용 시에는 케쉬나 바인드 기능을 사용
5.0과 
       6.0에서는 데이터윈도우에 새로운 데이터 형식이 있으므로 해당 형식에 맞게 지정
int
long
real 
4.19 
       조회 전 데이터윈도우와 테이블 비교 
 
파워빌더는 조회 전 데이터윈도우에 정의된 정보와 테이블의 내용이 일치하는지 미리 조사 한 후 조회
DBParm 속성 지정
결과치 비교 조사 취소: 

SQLCA.DBParm = 
         'StaticBind=1'
 

결과치 비교 조사 : 
         

SQLCA.DBParm = 
         'StaticBind=0' 
5 장: 
     그 외 사항
 
애플리케이션 성능 저하

애플리케이션 여는 시간

포커스 이동

DDDW가 늦게 열림

윈도우 활성

라이브러리 관리

시스템 구성

  
 
5.1 
       애플리케이션 성능 저하 
 
열었으면 닫아야 함
생성했으면 제거도 하여야 함
OpenUserObject( 
       )을 사용하였으면 CloseUserObject( )도 기술
OpenTab( ) 
       을 사용하였으면 CloseTab( ) 도 기술
연결하였으면 연결 종료도 하여야 함 
5.2 
       변수 선언 없이 생성 
 
변수 선언 없이 유저오브젝트를 생성하지 말 것
n_trans = CREATE 
         n_trans
문장 상으로 문제는 없으나 계속적으로 필요 없는 것이 생성됨 
5.3 
       애플리케이션 열기 
 
애플리케이션 시작 시에 다음에 필요한 작업을 하는 것도 고려 해 볼만 함
데이터베이스 연결 및 초기화
코드 테이블 조회
보안
만약에 애플리케이션 여는 시간이 문제라면 메인 윈도우에서 처리 
 
 
5.4 
       데이터윈도우 컬럼 간 이동 
 
ItemChanged 
       이벤트
ItemFocusChanged 
       이벤트
RowFocusChanged 
       이벤트
데이터 검증 룰
계산 필드
조건부 수행 
5.5 
       컨트롤 간 이동 
 
LoseFocus 
       이벤트
GetFocus 
       이벤트 
5.6 
       포커스 이동 시 문제점 해결 
 
중요하지 않은 과정은 Post
스크립트 수정
데이터 조회 시점 변경
데이터윈도우 오브젝트 점검
앤시스터 스크립트 확인 
5.7 
       DDDW가 늦게 열림 
 
각 DDDW가 각각 조회하는 것보다는 공유
pbm_dwndropdown 
       이벤트 점검 
5.8 
       윈도우 활성 
 
윈도우 활성이 늦으면 Activate, DeActivate 이벤트를 점검
시간이 걸리는 데이터조회는 
         Post
Activate 
         이벤트에 메뉴 관련 로직은 삼가
쉬트를 관리하기 위한 로직이 Activate 이벤트에 있다면 GetFirstSheet( ), 
         GetNextSheet( ), GetActivateSheet() 함수로 대치하여 전개 
5.9 
       라이브러리 관리 
 
대규모 애플리케이션인 경우 
       SetLibraryList( ) 함수를 이용하여 라이브러리 찾는 순서를 변경하는 것도 고려
앤시스터 오브젝트가 있는 라이브러리는 처음으로
하위시스템으로 전환시
사용자에 따라 사용하는 부분이 다를 경우 
5.10 
       오브젝트 재생성 
 
구조상 변화 시 재생성
추가나 삭제:
인스턴스나 쉐어드 변수
오브젝트 함수
이벤트 전부
윈도우나 유저오브젝트의 컨트롤
메뉴 오브젝트의 메뉴 아이템
사용자 정의 이벤트 선언이나 삭제 
5.11 
       라이브러리 최적화 
 
한 라이브러리 오브젝트 개수는 
       50 ~ 60 개
한 라이브러리의 크기는 800 
       K
PBL의 조각난 부분을 최적화 하면
개발 시 실행이 빠름
하드디스크 공간을 작게 사용
재생성 후 최적화 
5.12 
       시스템 구성 
 
연장 메모리 사용
메모리 추가
디스크 케싱 사용
배경 그림 비사용 
낮은 해상도 사용
DOS 환경 파일 숙지
CONFIG.SYS
AUTOEXEC.BAT
영구 스왑 파일 사용
스왑 파일을 네트웍 상에 두지는 말 것
하드디스크 조각 모음을 정기적으로
하드드라이브의 속도와 디스크 분할 확인
Windows 
       3.1일 경우 SmartDrive 사용
Windows 환경 파일 숙지
WIN.INI 
         
SYSTEM.INI
되도록 이면 큰 메모리 사용
Windows 3.1: 
         16M
Windows 95 : 32M 
         
개발 시 사용자 환경을 고려
사용자 환경에서 테스트
서버 용량 증대
파워빌더 실행 모듈이 있는 디렉토리는 Path제일 처음 위치로



감사히 잘 읽겠습니다.
출처 : http://www.softpackage.com/bbs/bbs/content.asp?grp=devforum&board=pbuilder&num=44&opt=
반응형

댓글