가장 빠른 압축 알고리즘들 테스트: QuickLZ와 Snappy(by Google)

압축프로그램 세상에서는 당연히 압축률[각주:1]이 높은 게 갑(甲)이다.
물론 태생적인 이유[각주:2]가 가장 큰 이유일 것이다.
지금은 하드용량도 엄청나게 커졌고, 네트워크도 훨씬 좋아졌지만, 압축 프로그램을 결정하는 주요 잣대는 여전하다.

그런데, 사실 조금만 눈을 돌려보면 압축 알고리즘에 요구되는 미덕이 언제나 압축률만인 것은 아니다.
적당한 압축률에 무척 빠른 알고리즘이 더 필요한 경우도 많다.

업무 중 이런 경우를 만나게 되어, 이런 경우를 위해 특화된 알고리즘들을 찾아봤다.
대략 FastLZ, QuickLZ, Snappy 등이 눈에 띄었다.

이 중 FastLZ는 다른 둘에 비해 속도가 좀 느려[각주:3] 테스트에선 제외하고, QuickLZ와 Snappy를 테스트해봤다.
이런 빠른 압축 알고리즘의 큰 특징은 허프만 코딩을 안 쓴는다는 것인데, 덕분에 두 방식 모두 원본의 흔적이 많이 보였다.

Snappy로 압축한 VCi.exe의 일부. "This program cannot be…"가 보임.



0. 비교 대상 알고리즘 및 환경

a. Snappy

구글의 내부 파일시스템에서 널리 사용하던 알고리즘을 공개한 것이 바로 이 Snappy이다.
덕분에, 이 알고리즘의 가장 큰 장점은 뭐니뭐니해도 검증된 안정성이다.


b. QuickLZ

홈페이지를 보면 무조건 지들이 킹왕짱 가장 빠르다고 한다.
가장 널리 사용되는 zlib과 비교해보면 압축속도가 5.6배나 빠르다고 한다.

QuickLZ는 1~3의 3가지 레벨이 있다.
1은 압축시간은 빠르지만, 압축률이 높지 않고, 3은 압축시간이 느린 대신 압축률이 높고 복원 시간이 짧다.


c. 컴파일 및 운영 환경

- CPU: Core2 Quad Q6600 @2.4GHz
- Memory: 4GB
- OS: Windows 7 x86
- Compiler: Visual C++ 6.0(32 bit)

두 알고리즘 모두 특히 64비트 환경에서 엄청 빠르다고 자랑하는데, 여건상 32비트에서만 테스트했다.
이게 여러모로 아쉽기는 한데, 이거 하나 테스트 하려고 Windows 7 x64를 설치하기엔 너무 손이 많이 가서 포기.

압축 대상은 실행파일 하나(VCi.exe: 184,320 Bytes)와 C언어 소스파일 하나(quicklz.c: 18,898 Bytes)로 정했다.
특별한 이유는 없다. 그냥 내 맘이다.

그리고, 같은 압축을 5000번씩 돌린 시간을 측정했다.
워낙 빠른 알고리즘들이라 몇십번 단위로는 비교할만한 숫자가 나오지를 않았다.



1. 압축된 파일 크기

바이너리 파일(VCi.exe)은 QuickLZ의 압축능력이 돋보였다.
압축률이 가장 떨어지는 Level 1에서도 Snappy보다 압축률이 높았다.

VCi.exe를 압축했을 때 파일 크기


C 소스 파일(quicklz.c)은 Snappy가 QuickLZ level 1보다는 높은 압축률을 보였지만, level 2보다는 낮았다.
QuickLZ 쪽의 기울기는 비슷하다는 점도 눈의 띈다.

quicklz.c를 압축했을 때의 파일 크기


대략 다음과 같은 점을 추측할 수 있었다.

- QuickLZ가 Snappy에 비해 전체적인 압축 능력이 뛰어나다.
- Snappy는 바이너리 파일에 대한 압축능력이 텍스트 파일에 대한 압축능력보다는 상대적으로 떨어진다.


2. 압축/복원 시간

서두에서 얘기했듯이, 이 알고리즘들의 핵심은 압축률이 아니다. 시간이다.

바이너리 파일(VCi.exe)에 대해서는 QuickLZ의 level 1에서의 압축 시간은 무시무시했다.
184KB 정도의 파일을 압축하는데 한번에 1ms도 걸리지 않았다. (아래 그래프는 무려 5000회 압축할 때 소요시간임)

하지만, QuickLZ의 level 3는 압축시간이 너무 느리다. (사실 이 속도는 zlib보다도 느린 수준임)
level 3는 큰 쓸모가 없을 것 같다.

Snappy는 사실상 QuickLZ와 큰 차이가 나지 않는 성능을 보여줬다.
QuickLZ level 1보다는 압축 시간이 더 걸렸지만, level 2보다는 시간이 덜 걸렸다.

VCi.exe를 압축/복원 할 때의 소요 시간


C 소스 파일(quicklz.c) 압축의 전체적인 추세는 바이너리 파일(VCi.exe) 때와 유사하다.
단지, Snappy의 압축 시간이 QuickLZ level 2보다도 더 걸렸다는 정도는 생각해볼만 하다.

quicklz.c를 압축/복원 할 때의 소요 시간


여기서 판단할 수 있는 내용은 이렇다.

- 압축률에 비해 압축/복원에 소요되는 시간은 큰 편차가 없다.
- QuickLZ level 3은 사실상 별 쓸모가 없다. 압축시간은 오래 걸리는데, 압축률는 너무 낮다.


3. 결론

대략 몇 가지 결론을 내릴 수 있었다.

- 압축률을 거의 무시할 수 있는 즉, 대충 압축을 하기만 하면 되는 상황이라면 QuickLZ level 1은 엄청난 매력이 있다.
- 압축률이 조금은 아쉽다면 QuickLZ level 2가 합리적인 선택일 것이다.


  1. 압축률 외에 안정성도 아주 중요한 요소임. 안정성은 사실 어떤 경우에도 양보될 수 없는 덕목임. [본문으로]
  2. 원래 파일 압축은 느리고 불안정한 전화망에서 파일을 조금이라도 더 빠르게 전송하기 위해 연구되기 시작되었음 [본문으로]
  3. 이렇게 얘기해도 엄청나게 빠름. 그냥 상대적으로 느리단 얘기임 [본문으로]
Trackback 0 Comment 7
  1. 타치코마 2011.08.22 17:22 address edit & delete reply

    압축 풀 경우 보통 다른 압축 프로그램으로 폴 경우가 많을 텐데... 그럴 때는 어떨까요? 혹은 대용량(4G 이상) 파일들은 어떻게 결과가 나올지 궁금하네요~

    • Favicon of http://zockr.tistory.com BlogIcon BLUEnLIVE 2011.08.22 18:52 address edit & delete

      다른 프로그램으로는 안 풀립니다. Snappy, QuickLZ 모두 각자의 압축 알고리즘입니다.

      두 알고리즘 모두 메모리 내부에서만 동작하며, 대형 파일을 압축하려면 일정 단위로 잘라서 압축해야 됩니다.

      즉, 4GB 이상 파일은 인터페이스를 구성하기 나름입니다.

  2. Favicon of http://salm.pe.kr/ BlogIcon koc/SALM 2011.09.11 14:56 address edit & delete reply

    QuickLZ level 3 은 대용량 압축이라면 의미가 있겠네요.
    한 번 만들어두고 지속적으로 보관하면서 주구장창 읽기만 하는 파일도 많거든요. 그럴 경우 압축시간이 오래 걸리더라도 읽는 시간이 짧아야 하잖아요.
    위 그래프를 보니 level 2의 절반 시간이니 충분히 유용하리라 생각합니다.

    • Favicon of http://zockr.tistory.com BlogIcon BLUEnLIVE 2011.09.11 17:59 address edit & delete

      문제는 QLZ l3은 zlib(사실상의 국제표준인 zip의 코어)에 비해 느리고 압축률이 낮다는 겁니다. ㅎㅎ
      이 글에선 빠졌는데, 사실 zlib, 7zip(LZMA)까지 다 테스트를 했습니다.

    • Favicon of http://salm.pe.kr/ BlogIcon koc/SALM 2011.09.12 20:50 address edit & delete

      설마... 압축 해제 시간도 느립니까?
      위 표만 보면 압축 해제 시간이 절반인데요. @,.@

    • Favicon of http://zockr.tistory.com BlogIcon BLUEnLIVE 2011.09.13 11:30 address edit & delete

      복원 시간은 빠릅니다.
      문제는 압축 시간 자체가 너무 느리다는 겁니다.

  3. TheSoas 2012.06.22 12:54 address edit & delete reply

    대용량파일 기준으론 확실히 level3에 관심이 계속가네요.
    압축하는 건 한번이고 읽는 횟수가 잦은 대용량 압축일땐..