Cág <ca6c_at_bitmessage.ch> wrote:
|Steffen Nurpmeso wrote:
|> Hello, for your possible interest.
|>
|> In a thead for the LUGA(ustria) i eventually had to time some
|> compression algorithms and wondered why zstd is so slow, but
|> especially so the decompressing stage, which a key feature of this
|> one. It turns out that the -Os compilation causes, well, drama-
|> tical performance degradation. I compiled my own with -O3 and the
|> difference is up to factor four. Just one example:
|
|What about -O2? Also what are the differences in binary sizes? Are you
|using gcc? If yes, try clang.
I thought it could be of interest for those who have many files or
whatever. Factor four is not nothing, especially if it is lost at
the bottommost level of computing.
In some private message i responded
Not really comparable since it found development stuff of other
archivers and compiled that in -- he adds more and more support
for other archive formats and i think that will end up like tar
a.k.a. libarchive umbrellas do. I do not know how i could have
an isolated quickshot or what make flags i would have to use to
get a stripped version that is comparable. (Too lazy, too late.)
But sure it will be somewhat larger, -Os is like -O2 (?) with some
reduction -- then again this is not chromium or something but
a (per se) small archiver, and factor four on decompression side
is drastical. It may also be platform dependent. I mean, for my
use case that is all right (but now that i have the binary around
it stays for a while), but if it would drive a compressed file
system or if i had a lot of compressed files to deal with
regulary, or if i had a server with database or whatever and it
would base on such files, then it would matter. (That is why
i said FYI.)
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
---
Unsubscribe: alpine-user+unsubscribe_at_lists.alpinelinux.org
Help: alpine-user+help_at_lists.alpinelinux.org
---
Received on Wed Mar 14 2018 - 19:15:51 UTC