search

MommyHeather / AdvancedBackups

BSD 3-Clause "New" or "Revised" License
21 stars 5 forks source link

Bug report : #76

Closed thowtue closed 3 weeks ago

thowtue commented 3 weeks ago

Describe the bug Compression lvl seems not to compress more at lvl 9 than lvl 4 or 1

To Reproduce Steps to reproduce the behavior: I tried different ratio compressions settings (in: config.advancedbackups.zips.compression) and my fullbackup .zip file is around the same size +- 2mb on around 700mb for all backups made.

The config.advancedbackups.chains.compress is set to true as well so i don't understand what is going on.

Expected behavior Should compress more the .zip files at lvl9 than lvl1

Screenshots rty Top one is lvl9 bottom one is lvl1

Versioning :

Additional context

Jadan1213 commented 3 weeks ago

I would assume this is due to the compressibility of the files. There's generally diminishing returns the higher you go with compression, and the files can only compress so much.

MommyHeather commented 3 weeks ago

Yeah, things are pretty much as jadan said - compression is only so effective, and the compression level affects the goal, it just can't always be acheived.

It's also worth noting that the compression level in the config is (correctly) being passed to java's builtin ZipOutputStream, which handles the actual act of compressing - which does mean that if there is an issue, it's not really one I could fix as it'd be an issue in your build of java.

thowtue commented 3 weeks ago

Allright thank you

Jadan1213 commented 3 weeks ago

Allright thank you

My recommendation, to avoid wasting CPU cycles, would be to leave it at 1. You could try 2 or 3 if you really want, but it doesn't appear that it will make very much difference.

thowtue commented 3 weeks ago

Since changing the value doesn't seem to change anything i've put back the default value of 4. I don't think it changes anything with CPU use since it takes same amount of time and no more resources from the CPU when compressing at lv1 than lvl9