Executable packers unpacking performance tested.

Discuss anything related to portable freeware here.
Message
Author
User avatar
webfork
Posts: 10823
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Topic Pollution

#16 Post by webfork »

I'm pretty sure webfork was trying to respond to m^(2)'s thread regarding "Executable packers unpacking performance tested", and hit "New Topic" instead of "Post Reply" on accident.
Yeah ... sorry about that. I edited my initial message to hopefully cut down on the confusion.
Last edited by webfork on Wed Nov 19, 2008 8:59 am, edited 1 time in total.

User avatar
webfork
Posts: 10823
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

compression scale

#17 Post by webfork »

[Moderator note: these two topics were re-merged as requested.]

---

> Can any moderator join the 2 topics?

Please.

> I'm disappointed by application's slowness if it doesn't show up instantly. After 1 second I get bored. After 3 - I'm getting angry. It changes with application's complexity, but slightly.

Agreed. Instead of just leaving this all to user preference, let me make a recommendation using this scale:
  • Often used / creative (low) <--> Rarely used / system management (high)
Further, for at least a hundred programs on here, even high compression would marginally impact their already immediate startup time. Those hundred different programs run by hundreds of different developers who may or may not have knowledge of how to further internally compress libraries and executables. An ideal example is registry tweaking software, which used only rarely and is perfect for very high compression.

For those programs that do not start up that fast (especially Firefox, GIMP and other tools m^(2) mentioned) instant start up mimics our own responses. When you think of a topic or an idea you want the tool that will make that idea come into play as fast as possible. For example, I seem to be unable to leave WordPad behind -- even though its an ancient and very featureless program -- simply because of its fast startup time. Often its the ability to write down an idea before I get distracted is more important than using one of the hundreds of tools (like PSPad) that's portable and 100x better.

User avatar
m^(2)
Posts: 890
Joined: Sat Mar 31, 2007 2:38 am
Location: Kce,PL
Contact:

Re: compression scale

#18 Post by m^(2) »

webfork wrote:> I'm disappointed by application's slowness if it doesn't show up instantly. After 1 second I get bored. After 3 - I'm getting angry. It changes with application's complexity, but slightly.

Agreed. Instead of just leaving this all to user preference, let me make a recommendation using this scale:
  • Often used / creative (low) <--> Rarely used / system management (high)
Further, for at least a hundred programs on here, even high compression would marginally impact their already immediate startup time. Those hundred different programs run by hundreds of different developers who may or may not have knowledge of how to further internally compress libraries and executables. An ideal example is registry tweaking software, which used only rarely and is perfect for very high compression.

For those programs that do not start up that fast (especially Firefox, GIMP and other tools m^(2) mentioned) instant start up mimics our own responses. When you think of a topic or an idea you want the tool that will make that idea come into play as fast as possible.
I don't think you can judge how often is application to be used so easily, ie. registry cleanup may be a part of one's job.
IMO as long as it may make a noticeable difference, speed should go before size.

In general, I strongly believe that in many cases compression *should* be used to speed things up.
CPU power is cheap and HDD speed - expensive.
Executables are very bad kind of data for doing this because they are accessed randomly. However in case when data is being accessed in reasonably big chunks and you know this when designing an application, you can gain a lot. NRV2E running on 4 cores would give you 400 MB/s. With a modern CPU 600-800.

Even compressing data that your program saves is often good. I play with compressors quite a lot and for almost all data that I tried, there are packers that work faster than XCOPY.
Actually it's being used already, i.e. with Office documents. Both OpenOffice and MS Office formats use zip to store their files. I hope we'll be seeing more such uses.
webfork wrote:For example, I seem to be unable to leave WordPad behind -- even though its an ancient and very featureless program -- simply because of its fast startup time. Often its the ability to write down an idea before I get distracted is more important than using one of the hundreds of tools (like PSPad) that's portable and 100x better.
Some like AngelWriter more than notepad. It's just as fast and has a few more buttons. ;)

User avatar
webfork
Posts: 10823
Joined: Wed Apr 11, 2007 8:06 pm
Location: US, Texas
Contact:

Scale problems.

#19 Post by webfork »

> I don't think you can judge how often is application to be used so easily, ie. registry cleanup may be a part of one's job. IMO as long as it may make a noticeable difference, speed should go before size.

> In general, I strongly believe that in many cases compression *should* be used to speed things up. CPU power is cheap and HDD speed - expensive.


Ah yes -- both excellent points.

> Both OpenOffice and MS Office formats use zip to store their files. I hope we'll be seeing more such uses.

Agreed.

> Some like AngelWriter more than notepad.

I'll check that out.

User avatar
m^(2)
Posts: 890
Joined: Sat Mar 31, 2007 2:38 am
Location: Kce,PL
Contact:

#20 Post by m^(2) »

Update:
I tested more things including missing upx nrv2d.

New things:

Code: Select all

FreeArc -mrep                  89407238  0.875
UPX NRV2D                      36717568  0.984(1)
7z -mx9 -m0=Deflate64          36301274  3.046(3)
7z -mx9 -m0=Deflate            37071821  3.140(3)
FreeArc (best)                 26160188  6.843(1)(4)
BALZ                           32123543 13.875
Flashzip m1 s1 b5              33501960 13.875
bcj2+delta+rep:200m:a99+rzm    24729161 18.656(1)(3)

(1) "The best" mode. Nothing beats it in both size and time
(3) Global time, includes IO.
(4) Switches: -mexe+delta+lzma:128m:bt4:fb273:mc256 -ep -i0 / -i0
(5) Because bcj2+delta+rep:200m:a99+rzm is not a single archiver, I consider this one "the best" too
Full table:

Code: Select all

LZOP -9 -F                     46023879  0.656(1)
Quick -3                       49342629  0.687
Quick -2                       52595713  0.718
Quick -1                       56463297  0.734
LZSS ex                        47882127  0.828
FastLZ -2                      57871075  0.875
FreeArc -mrep                  89407238  0.875
FastLZ -1                      59193978  0.921
FastLZ opt -1                  59383836  0.921
FastLZ opt -2                  58255894  0.953
UPX NRV2B                      37060096  0.968(1)
UPX NRV2D                      36717568  0.984(1)
UPX NRV2E                      36585472  1.000(1)
tor -12 -c1                    41928945  1.015(2)
LZTurbo 19                     38773267  1.046
4x4 tor:1:128m                 62324238  1.078
Quick -0                       55693688  1.125
LZTurbo 29                     36596233  1.187
tor -12 -c2                    38032542  1.250(2)
FreeArc -1xx                   42219499  1.359
LZTurbo 39                     36982013  1.578(3)
FreeArc -2xx                   38260468  1.640
CabArc LZX:21                  35307686  1.671(1)
nz -cd                         34508054  1.781(1)
tor -12 -c3                    34284810  1.796(1)
4x4 tor:4:128m                 41509713  2.156
Thor e2                        50217340  2.281
Thor e5                        41955492  2.406
FreeArc -3xx                   31746653  2.546
Thor e1                        53220550  2.546
nz -cD                         31159412  2.687(1)
4x4 tor:12:48m                 35831898  2.812(3)
Thor e3                        45614772  3.031
tor -12 -c4                    33729113  3.046
7z -mx9 -m0=Deflate64          36301274  3.046(3)
nz -cf                         44669276  3.078
7z -mx9 -m0=Deflate            37071821  3.140(3)
LZTurbo 49                     33727604  3.468(3)
FreeArc -4xx                   31192925  3.579
4x4 12:48m                     31007550  4.781(1)(3)
slug                           43081286  5.140
nz -cF                         38839581  5.578
Thor e4                        41243524  5.656
UPX LZMA                       28961792  6.453(1)
FreeArc (best)                 26160188  6.843(1)(4)
FreeArc -9x                    26162769  6.843
7z -mx9                        25791853  7.515(1)
LZTurbo 59                     33079469  9.734(3)
BALZ                           32123543 13.875
Flashzip m1 s1 b5              33501960 13.875
rzm                            25498961 15.875(1)
bcj2+delta+rep:200m:a99+rzm    24729161 18.656(1)(3)
nz -co                         25121167 23.562(1)(5)
Upack                          28923468 37.422
nz -cO                         23867674 57.531(1)

(1) "The best" mode. Nothing beats it in both size and time
(2) "The best" loseless.
(3) Global time, includes IO.
(4) Switches: -mexe+delta+lzma:128m:bt4:fb273:mc256 -ep -i0 / -i0
(5) Because bcj2+delta+rep:200m:a99+rzm is not a single archiver, I consider this one "the best" too

Post Reply