효율적인 온라인 Hex Editor, HexEd.it

최근에 웹툴로 Hex Editor를 제작하려다가,

효율적인 구조 설계는 다 했는데(약 1시간 소요) 추가로 넣을 기능이 있나 다른 제품을 찾아보다가 HexEd.it을 찾게 되었습니다.

너무 잘 만들어져있어서 새로 만들려던건 접고, 추천하기로 결정하였습니다.

 

제가 생각했던 브라우저에서 메모리 최적화 및 출력 최적화가 모두 적용되어있고, 다양한 기능이 있어 추천글을 작성하게 되었습니다.

HexEd.it

대용량 파일을 브라우저에?

대용량 파일을 브라우저에 표현하면 메모리가 터집니다.

DOM에 모든 값을 출력하면 오버헤드가 엄청난데, 만약 스크롤을 하게되면 CPU는 최대(크롬의 경우 단일코어이므로 100/코어수 %)를 나타내고, 메모리는 이미 꽉차있는 상태일것입니다.

 

하지만 제대로 최적화를 한다면 설치형 프로그램 못지않은 최적화가 가능합니다.

 

제가 설계한것도, 저 제품도 동일하게 스크롤을 따로 만들었습니다.

 

제가 최적화 설계하던걸 위주로 저 제품에 대해 안내하는 글을 작성해보려고 합니다.

따로 제품에 대해 코드분석을 한게 아닌 제가 만들던거 위주로 작성하려고 합니다.

 

 

스크롤 바

기본적으로 DOM에 모든정보를 다 넣어 내장된 스크롤바를 사용하는게 아닌 필요한 출력만 DOM에 표시합니다.

스크롤바는 실제 브라우저의 스크롤바가 아닌 JS로 처리되는 스크롤바입니다.

 

저 또한 이렇게 설계를 했는데, 대용량의 파일이라면 + 모든 내용이 브라우저 안에 들어가 있으면 브라우저는 무조건 멈춥니다.

 

그렇기 때문에 화면에 표시되는 내용만 표시하려면, 스크롤바 위치에 따라 ArrayBuffer에서 가져와서 보여주면 됩니다.

 

사실 이게 대용량 파일을 보여주는 최적화의 전부로 최적화 되고 안되고의 차이는 10MB파일 기준 1000배 이상 차이가 납니다.

파일 용량이 커질수록 그 이상의 차이가 나게되는데 조금만 용량이 커진것을 표현하면(50MB 정도되는 파일은 대부분 웹브라우저에서 표시가 잘 되지 않습니다.) 메모리 사용량도 폭증하게 됩니다.

 

웹브라우저는 상단의 코드도, 하단의(안보이는 곳의)코드도 모두 실행이 되어야합니다.
원래 이렇게 설계되었고요. 때문에 대용량 파일이 DOM에 들어가면, DOM파싱 처리속도가 매우 늦어지며, 브라우저가 멈추게 됩니다.

 

 

스크롤 바 위치

위치는 현재 표시되는 값의 비율을 이용해서 표시하면 됩니다.

예를들어, 10만개중 1만번째 위치라면 10%에 스크롤바가 있으면 됩니다.

 

스크롤 바 크기

min-height를 지정하고, 파일 크기(디스플레이 크기에 따라)에 역으로 스크롤 바 크기를 지정하면 됩니다.

 

디스플레이

slice함수를 이용해 스크롤 바 위치에 표시될 내용을 가져오면 됩니다.

Array.prototype.slice([begin[, end]])

 

예를들어 uint8<Uint8Array>로 저장되어있다면?

uint8.slice(begin, begin+640);

begin에는 스크롤바 위치에 따른 값이 들어가면 될겁니다.

 

이렇게 만들경우 메모리에는 사용하는만큼만 내용이 들어가고 CPU는 복사본인 640(16개 * 40줄)만큼만 처리하면 되므로 CPU 100%를 찍는 현상도 없어지게 됩니다.

 

 

hexed.it 바로가기

HexEd.it - Browser-based Online and Offline Hex Editing