|
|
|
#1
|
|||
|
|||
|
Today I tried something different. Rather than focusing on general compressors, I decided to compare default multimedia compressor of FA vs alternatives. Specifically in this test, I was focusing on graphics .bmp files and default $bmp of FA which use grzip for this purpose. I compared it to similar alternatives suitable for graphics as well as more general compressors such as lolz.
Test consisted of around 1.3gb of .bmp files. First and most important thing, by default FA process each file separately. I tarred them into single file and compared default FA's $bmp algo how it cope with separated files vs 1 put together: original: 1.33gb -FA -mbmp on dir of files(internally each processed separately and put into archive = default behavior): 539mb From now all following results are on tarred single file: Code:
-FA -mbmp: 469.61mb !!! -bcm: 531.96mb -bsc: 518.54mb -bsc -m5: 518.86mb -dlz: 489.85mb -uharc -m3: 457.73mb -lolz: 451.42mb -FA -xppmd: 483.05mb Now, dlz and lolz re specialized on dds textures and there they kick ass ~10%(I already tried), but for common image formats, dont bother. Default FA's grzip rules, it is internal thus supporting pipelining so no disk trashing, it is extremely fast, multi-threaded and is just great overall. However, as you see in this test default behavior of processing images separately hurt *big time*. How to solve it? Simple, add rep before bmp: $bmp=bmp >> $bmp=5rep+bmp Then when you use something like: FA -m5/$bmp=5rep+bmp -mc:rep/srep... what will happen is that FA will tar and srep images first before applying grzip. And btw, adding rep or srep help even further, it doesnt hurt at all. |
| Sponsored Links |
![]() |
| Thread Tools | Search this Thread |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Return To Castle Wolfenstein info | the_fsr | PC Games | 0 | 01-04-2004 18:20 |