«   2020/07   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  
Tags
more
Archives
Today
0
Total
1,731
관리 메뉴

넓적부리의 작업실

WinBuilder 스크립트 파싱 코드 구현 및 현황 본문

CSharp/PEBakery

WinBuilder 스크립트 파싱 코드 구현 및 현황

넓적부리 2016. 9. 7. 03:15

WinBuilder 재구현체 PEBakery의 소스코드는 여기서 보실 수 있습니다.

https://github.com/ied206/PEBakery

아직 완성되지 않았고 코드가 나날이 갈아엎이고 있는 점 유의해 주세요.


WinBuilder의 프로젝트는 여러 개의 스크립트로 구성되어 있습니다.

이 스크립트들은 크게 세 가지 부분으로 나뉘어집니다.


1. Main 섹션

스크립트의 이름, 버젼 등의 정보가 담겨 있으며, INI 파일의 구조를 가지고 있습니다.

길이가 짧은 편이어서 메모리에 올려둬도 영향이 별로 없습니다.


2. Variables 섹션

밑의 코드 부분에서 사용할 변수를 미리 지정합니다. 역시 INI 파일의 구조를 가지고 있습니다.

역시 길이가 짧은 편이라 메모리에 올려둬도 영향이 별로 없습니다.-


3. Code 섹션들

[Process] 섹션을 위시한, 코드로 이루어져 있는 섹션들입니다.

여기는 INI 구조가 아닌, WinBuilder 자체 스크립트 언어로 기술되어 있습니다.

스크립트 엔진에서 다양한 위치의 코드를 종횡무진 읽는 만큼, 일단은 전부 다 메모리에 올리는 것으로 구현하였습니다.


4. Attach 섹션들

파일을 Base64로 인코딩하여 저장하는 섹션들입니다.

아마 zlib 같은 것으로 압축이 들어가지 않았을까 싶습니다만, 자세한 것은 더 알아봐야 합니다.

용량이 크기 때문에 필요한 시점에만 메모리로 읽어오는 것이 좋습니다.



스크립트를 파싱하는 부분을 처음 구현했을 때는, 첨부된 파일을 포함한 스크립트 전체를 메모리에 올려서 처리했습니다.

그 결과 벌어진 일은....

GC : 야 이놈아  좀 작작 써라! 한계에 도달했다!


4초만에 램 3GB 사용량을 달성했습니다 (...)

(64비트 Windows에서, 32비트 프로세스가 최대로 쓸 수 있는 메모리의 양은 3GB입니다)


그래서 파싱하는 코드를 며칠에 걸쳐 한줄씩 읽어 처리하도록 갈아엎었습니다.

그러나, 램 사용량은 270MB로 10%까지 낮췄으나 소요시간이 25초나 걸리는 사태가 발생했습니다.

(WinBuilder 082는 동일 환경에서 로딩시 35초가 걸립니다)

하지만 여기서 포기하면 뭔가 아쉽죠.


주변의 자비로운 C# 마스터의 도움을 받아 멀티쓰레딩을 도입하고 최적화를 하여 소요시간을 다시 12초까지 낮췄습니다.

여전히 4초보다 느리지만, 높은 공간복잡도를 잡기 위해 지출한 비용 치고는 싼 편입니다.

(컴퓨터과학을 배우신 분들은 알겠지만, 소요시간(시간복잡도)과 메모리 사용량 (공간복잡도)은 반비례하죠)


프로그래머의 로망, CPU 사용률 100%가 보이십니까?



PEBakery 구현 현황

- WB 스크립트 언어 파싱이 대부분 구현되었습니다.

- WB 스크립트 파일 파싱이 구현되었습니다. (높은 메모리 사용량 해결)

- 프로젝트 폴더 내 전체 스크립트 파싱이 구현되었습니다. (높은 메모리 사용량 해결)

- WB 스크립트 명령어 중 10%가 구현되었습니다.

- 엔진에서 하나의 스크립트를 처리할 수 있습니다.

- 로그 시스템이 시험적으로 구현되었습니다.
- 변수 처리가 구현되었습니다.


해결해야 할 것

- 프로젝트 폴더 내 전체 스크립트 파싱시 코드가 없는 Container 스크립트를 가려내야 합니다.

- 엔진에서 여러 스크립트를 처리하려고 시도할 시 워 문제로 인해 프로그램이 죽는 현상이 발생합니다.


0 Comments
댓글쓰기 폼
Prev 1 2 3 4 5 6 7 8 Next