티스토리 뷰

MoviX와 같은 툴에 눈길이 가는 이유 중 하나는 '저사양에서 구동을 원하기 때문' 일 겁니다.

주로 관심이 가는 부분은 CPU,VGA,RAM 정도일텐데

CPU나 VGA는 이견이 많을 수 있는 부분이므로 주로 메모리에 대해서 적어보겠습니다.



1. MoviX에서 현재 사용 중인 메모리 확인방법

메인메뉴에서 alt-f3 키를 사용하면 console로 나갈 수 있습니다. (프롬프트 상태)

콘솔에서 다시 메인메뉴로 가시려면 movix 라고 치셔도 되고 alt-f1 키를 사용하셔도 됩니다.

(여기서 movix를 재실행하면 movix가 중복실행되는 것 같습니다.

즉 메모리를 더 사용하게 되는 것이죠. 그에 비해 alt-f1을 쓰면

잠시 백그라운드로 전환된 기존의 movix 메뉴화면으로 되돌아 가게 됩니다.

그러므로 alt-f1 키를 쓰시기 바랍니다.)


프롬프트 상태에서 아래 경로의 파일을 열면 현재 메모리 상태를 확인할 수 있습니다.

/proc/meminfo

가장 간단하게 여는 방법은 'cat' 명령어를 쓰는 방법입니다.


즉 루트에서 cat /proc/meminfo 하시던지 혹은

루트에서 cd /proc 하신 후 cat meminfo 하셔도 되겠죠.



2. MoviX는 램드라이브에 어떤 것을 적재하나?

원배포자의 README 파일을 봐도 이에 대해 약간의 언급이 있지만

정확히 알고자 하면 시디에서 아래 경로의 소스파일을 보시면 알 수 있습니다.

/movix/rc.movix

 

- 기본적으로 적재되는 용량

위의 메모리 사용량 확인 방법으로 확인해보면 대략 55MB 정도입니다.

mplayer 구동에 필요한 부분까지 감안하면 최소 64MB 정도로 봐야 합니다.

(README 파일에서 MoviX 원배포자 역시 스왑파티션이 없을 경우 64MB를 최소로 권합니다.)


- 부가적으로 적재되는 용량

rc.movix 파일의 소스를 보면 아래의 것들은

적재 중 남은 메모리를 검사해보고 조건에 맞는 경우 적재하는 것으로 나옵니다.


. Samba 서버용 파일

. QuickTime 라이브러리 파일

. RealPlayer 라이브러리 파일

. Win32 라이브러리 파일

. Xamin 라이브러리 파일 (이건 뭔지 모르겠군요)

. 자막 파일 (폰트를 말합니다.)


이것을 순서대로 적재하는데 각각 적재조건이 다릅니다.

예를 들어 QuickTime 라이브러리는 20메가가 있어야 적재한다고 하고

RealPlayer 라이브러리는 15메가가 있으면 적재한다고 할 때

남은 용량이 18메가라면 QuickTime 라이브러리는 적재를 안 하고 넘어가고

그 다음에 RealPlayer 라이브러리는 용량이 되므로 적재를 하게 됩니다.

즉 각각의 패키지 별로 적재 조건이 있고 그 조건의 내용도 다르므로

메모리 여분이 있다고 위의 패키지들이 순서대로 적재되거나

메모리 부족 시 뒤의 패키지는 적재가 안 될 것이라고 장담할 수는 없습니다.


 

3. 메모리 적재 예

결론적으로 메모리가 64메가인 경우에는 아무것도 부가요소는 적재되지 않지만

72메가인 경우는 삼바와 폰트는 적재되고 4메가 정도가 남았습니다.

이것은 폰트 파일 용량에 따라 달라질 문제로 폰트를 gulim.ttc (12.8MB)만 넣었을 경우입니다.

그리고 재생은 도중에 튕기더군요. 76메가로 해줬을 경우는 재생까지 잘 되었습니다.


그러나 순서대로 적재되므로 72메가에서 더 늘려서 XX 메가가 되었는데

삼바가 적재된 후 삼바와 폰트 사이의 다른 것이 적재되고

그러고 나니 용량이 모자라서 폰트는 적재가 안 될 수도 있겠죠.


물론 128메가를 쓰는 경우는 모두 적재되고

96메가를 쓰는 경우는 Win32 라이브러리를 제외하고 모두 적재되었습니다.


 

4. 메모리 최적화 목적

불필요한 (제 기준이기도 하지만 대부분 그럴 겁니다.) 패키지 로딩을 안 하도록 하면


(1) 특정 용량의 메모리에서 특정 사이즈의 폰트 사용 시

정작 폰트는 로딩되지 않는 경우를 막을 수 있습니다.

사실 기본폰트들은 워낙 용량이 작기에 별 문제 없는데 한글 트루 타입 글꼴들은 용량이 상당하죠.

근본적인 원인은 폰트 파일 사이즈 때문인 것 같습니다.


(2) 부팅 속도 향상

메모리가 적다면 부가요소들은 원래 로딩되지 않으므로 그런 경우 큰 속도 차는 없을 겁니다.

다만 로딩할지 안 할지 검사하는 로직이나마 패스하게 되겠죠.

그러나 메모리가 충분한 경우에는 쓰지도 않을 패키지들을 로딩하느라

메모리를 잡아먹고 부팅속도를 늦추게 되므로 몇 초나마 가시적 효과가 있으리라 기대해봅니다.


 

5. 수정방법

부가적재목록 중 폰트 파일만 제외하고 모두 로딩하지 않도록 수정하겠습니다.

rc.movix 파일의 302 라인부터 447 라인까지를 제거해도 되고 주석처리해도 됩니다.


302 라인 바로 위의 getFreeRam 함수(? 메소드?)는

적재 중에 프리 메모리를 검사하여 남은 용량을 리턴하는 함수인데

나중에 폰트 적재 블록에서 또 사용되므로 그 부분은 제거 안 했습니다.


혹은 그 부분을 제거하는 대신 폰트 적재 블록에서 getFreeRam을 사용 안 하도록 수정하고

대신 무조건 폰트를 로딩하도록 해도 되겠죠.

(그러나 이 경우 미리 메모리 용량과 로딩할 폰트파일 용량을 따져보고 해야 겠죠.

이 다음 포스트에서 이에 대해서 다뤘습니다.)


만약 부가적재목록 중 폰트 외에도 쓰고자 하는 부분이 있다면

선택적으로 수정해야지 무조건 302~447까지 주석처리하거나 제거하시면 안 됩니다.


 

6. 최적화 후 메모리 사용량

아래 화면은 수정 작업 전에 128MB 메모리 사용 시입니다.

첫번째 박스 안에 잉여메모??약 30메가 정도로 나와있습니다.

그 다음 박스에는 부가적으로 로딩된 패키지에 관련된 파일들입니다.

사용자 삽입 이미지



이 아래 화면은 128MB 사용 시 수정작업을 거친 것입니다.

첫번째에서 잉여 메모리가 약 25MB 정도 늘었음을 알 수 있습니다.

또한 밑의 파일 목록에도 부가적인 패키지는 적재되지 않았음을 알 수 있죠.

사용자 삽입 이미지


참고로 둘 다 충분한 잉여메모리가 있으므로 재생능력 상 차이는 없으리라 생각됩니다.



7. 최적화 후 부팅시간 차이

부팅 시간은 2대에서만 테스트해봤습니다.

시간은 포스팅 시작부터 메인메뉴 뜰 때까지입니다.

 

(1) 코퍼셀 600@900 + 32X CD-ROM

수정 전 : 1분 26초

수정 후 : 1분 13초

 

(2) 투알셀 1.1@1.47 + 12X10X32X CD-RW

수정 전 : 55초

수정 후 : 1분 7초

 

ODD의 상태라는 것도 있으니 이 정도 결과로 저사양일수록

더 효과가 높다고 속단하긴 어려울 듯 보이지만 어쨋든 시간단축 효과가 있긴 합니다

 

차후에 제가 MoviX용으로 사용하는 저사양PC(데슈츠 400) 테스트 결과도 올리겠습니다.

 

 

8. 마치며...

기본적으로 적재하는 부분(즉 55MB 내에 속하는 부분) 역시 수정이 가능하리라 봅니다.

이 중 안 쓰는 패키지를 제거하여 64MB에서 한글자막을 포함한 MoviX의 원활한 재생도

가능하다면 하는 생각이 드는군요. 다음에 시간이 되면 뒤적거려서 해보도록 하지요 ^^

댓글
공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크