직접 만든 인코딩 변환 라이브러리의 속도를 테스트해보았습니다. MBCS에서 UNICODE로 혹은 그 반대로 매핑하는 2차원 배열을 만들어 놓고 참조하는 방식입니다. 테이블 데이타를 static 형식으로 코드에 삽입시켰더니, exe 파일이 400-500 kb 정도가 되는군요. (코드 페이지 = 932, 936, 949, 950)
꽁수를 안 쓰고 2바이트 매핑 테이블을 그대로 탑재시키면, 1M 정도였을 겁니다. 지금은 바이트 범위를 조사해서 필요 없는 부분은 저장하지 않는 방식을 사용합니다. gz 스트림으로 압축시키면 실행 파일의 크기를 더 줄일 수 있기(333k에서 256k로)는 한데, 용량 감소폭 대비 번거로움을 따져보면 그냥 쓰는게 나을거 같습니다.
아무튼 직접 만든 인코딩 변환 라이브러리의 속도를 비교해봅시다. 비교 대상은 System.Text.Encoding 객체입니다. libiconv도 하고 싶으나 솔직히 귀찮습니다.
400kb 정도 되는 한글 텍스트 파일(243943 유니코드 글자)을 가지고 MBCS로 인코딩하고 디코딩하는 속도를 재었습니다. 5번 재어서 평균 냈고 사용한 기종은 소니 엑스페리아 X1, Windows 6.1 한글판입니다. 컴파일러는 VisualStudio 2008 sp1 + Windows Mobile 6 SDK 입니다.
단위는 msec.
Encoding: Unicode -> MBCS. 즉, WideCharToMultiByte
Decoding: MBCS -> Unicode, 즉, MultiByteToWideChar
의외로 MS가 제공하는 라이브러리가 느렸군요.
생각보다 C#이 빠르다는 사실을 알 수 있습니다. 물론 빠른 속도를 내기 위해서 코드를 좀 간결하게 바꾸는 작업을 진행하긴 했지만 말입니다. 이것이 바로 JIT의 힘입니다. 좋군요.
꽁수를 안 쓰고 2바이트 매핑 테이블을 그대로 탑재시키면, 1M 정도였을 겁니다. 지금은 바이트 범위를 조사해서 필요 없는 부분은 저장하지 않는 방식을 사용합니다. gz 스트림으로 압축시키면 실행 파일의 크기를 더 줄일 수 있기(333k에서 256k로)는 한데, 용량 감소폭 대비 번거로움을 따져보면 그냥 쓰는게 나을거 같습니다.
아무튼 직접 만든 인코딩 변환 라이브러리의 속도를 비교해봅시다. 비교 대상은 System.Text.Encoding 객체입니다. libiconv도 하고 싶으나 솔직히 귀찮습니다.
400kb 정도 되는 한글 텍스트 파일(243943 유니코드 글자)을 가지고 MBCS로 인코딩하고 디코딩하는 속도를 재었습니다. 5번 재어서 평균 냈고 사용한 기종은 소니 엑스페리아 X1, Windows 6.1 한글판입니다. 컴파일러는 VisualStudio 2008 sp1 + Windows Mobile 6 SDK 입니다.
단위는 msec.
| 내거 Enc | 내거 Dec | C# Enc | C# Dec | |
| Unicode | 19 | 19 | 25 | 25 |
| UnicodeBE | 49 | 51 | 132 | 72 |
| UTF-8 | 60 | 86 | 88 | 134 |
| CP949 | 160 | 77 | 214 | 52 |
Encoding: Unicode -> MBCS. 즉, WideCharToMultiByte
Decoding: MBCS -> Unicode, 즉, MultiByteToWideChar
의외로 MS가 제공하는 라이브러리가 느렸군요.
생각보다 C#이 빠르다는 사실을 알 수 있습니다. 물론 빠른 속도를 내기 위해서 코드를 좀 간결하게 바꾸는 작업을 진행하긴 했지만 말입니다. 이것이 바로 JIT의 힘입니다. 좋군요.
