- 가장 빠른 압축 알고리즘들 테스트: QuickLZ와 Snappy(by Google)
- 컴퓨터야그/자작
- 2011. 8. 22. 08:30
압축프로그램 세상에서는 당연히 압축률이 높은 게 갑(甲)이다. 1
물론 태생적인 이유가 가장 큰 이유일 것이다. 2
지금은 하드용량도 엄청나게 커졌고, 네트워크도 훨씬 좋아졌지만, 압축 프로그램을 결정하는 주요 잣대는 여전하다.
그런데, 사실 조금만 눈을 돌려보면 압축 알고리즘에 요구되는 미덕이 언제나 압축률만인 것은 아니다.
적당한 압축률에 무척 빠른 알고리즘이 더 필요한 경우도 많다.
업무 중 이런 경우를 만나게 되어, 이런 경우를 위해 특화된 알고리즘들을 찾아봤다.
대략 FastLZ, QuickLZ, Snappy 등이 눈에 띄었다.
이 중 FastLZ는 다른 둘에 비해 속도가 좀 느려 테스트에선 제외하고, QuickLZ와 Snappy를 테스트해봤다. 3
이런 빠른 압축 알고리즘의 큰 특징은 허프만 코딩을 안 쓴는다는 것인데, 덕분에 두 방식 모두 원본의 흔적이 많이 보였다.
0. 비교 대상 알고리즘 및 환경
1. 압축된 파일 크기
2. 압축/복원 시간
3. 결론
물론 태생적인 이유가 가장 큰 이유일 것이다. 2
지금은 하드용량도 엄청나게 커졌고, 네트워크도 훨씬 좋아졌지만, 압축 프로그램을 결정하는 주요 잣대는 여전하다.
그런데, 사실 조금만 눈을 돌려보면 압축 알고리즘에 요구되는 미덕이 언제나 압축률만인 것은 아니다.
적당한 압축률에 무척 빠른 알고리즘이 더 필요한 경우도 많다.
업무 중 이런 경우를 만나게 되어, 이런 경우를 위해 특화된 알고리즘들을 찾아봤다.
대략 FastLZ, QuickLZ, Snappy 등이 눈에 띄었다.
이 중 FastLZ는 다른 둘에 비해 속도가 좀 느려 테스트에선 제외하고, QuickLZ와 Snappy를 테스트해봤다. 3
이런 빠른 압축 알고리즘의 큰 특징은 허프만 코딩을 안 쓴는다는 것인데, 덕분에 두 방식 모두 원본의 흔적이 많이 보였다.
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번씩 돌린 시간을 측정했다.
워낙 빠른 알고리즘들이라 몇십번 단위로는 비교할만한 숫자가 나오지를 않았다.
구글의 내부 파일시스템에서 널리 사용하던 알고리즘을 공개한 것이 바로 이 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보다 압축률이 높았다.
C 소스 파일(quicklz.c)은 Snappy가 QuickLZ level 1보다는 높은 압축률을 보였지만, level 2보다는 낮았다.
QuickLZ 쪽의 기울기는 비슷하다는 점도 눈의 띈다.
대략 다음과 같은 점을 추측할 수 있었다.
- QuickLZ가 Snappy에 비해 전체적인 압축 능력이 뛰어나다.
- Snappy는 바이너리 파일에 대한 압축능력이 텍스트 파일에 대한 압축능력보다는 상대적으로 떨어진다.
압축률이 가장 떨어지는 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보다는 시간이 덜 걸렸다.
C 소스 파일(quicklz.c) 압축의 전체적인 추세는 바이너리 파일(VCi.exe) 때와 유사하다.
단지, Snappy의 압축 시간이 QuickLZ level 2보다도 더 걸렸다는 정도는 생각해볼만 하다.
여기서 판단할 수 있는 내용은 이렇다.
- 압축률에 비해 압축/복원에 소요되는 시간은 큰 편차가 없다.
- QuickLZ level 3은 사실상 별 쓸모가 없다. 압축시간은 오래 걸리는데, 압축률는 너무 낮다.
바이너리 파일(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가 합리적인 선택일 것이다.
- 압축률을 거의 무시할 수 있는 즉, 대충 압축을 하기만 하면 되는 상황이라면 QuickLZ level 1은 엄청난 매력이 있다.
- 압축률이 조금은 아쉽다면 QuickLZ level 2가 합리적인 선택일 것이다.
'컴퓨터야그 > 자작' 카테고리의 다른 글
libjpeg.lib 오류 해결 (5) | 2011.09.27 |
---|---|
JPEG 라이브러리 성능 비교 (Visual C++) (1) | 2011.09.24 |
디카 메모리가 부족하다고 풍경을 마음에 담을 순 없다! (캐궁극++ 버전) (4) | 2011.08.04 |
TS/MTS → MKV 한방에 변환하기 (8) | 2010.12.05 |
오디오/비디오 싱크를 위한 리샘플 헬퍼 (9) | 2010.10.25 |
Recent comment