-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Faster startup using lz4? #19
Comments
@jb55 have you run benchmarks between squashfs and lz4? We'd be interested in those for AppImageKit, too. |
@probonopd I'm going off generic compression benchmarks where lz4 wins in speed by a large margin. I haven't tested lz4 in squashfs, although it looks like it's supported? |
You are right... |
We did some measurements using gzip (instead of bzip) and the difference is not too big (a few percent quicker). Would be interesting to give lz4 also a try (but arx doesn't implement it). |
Yeah I think biggest savings will come with "mounting" instead of "extracting". FUSE should give us that and I believe it's supported on most systems. |
over here, the bundle pre-unpacks the entire thing to a known directory, and generates things like a |
@cleverca22 clever |
but ive also ran into an issue, i'm treating the bundle purely as an installer/updater, but i cant run it from within the namespace for self-updating |
That will be much slower than loop-mounting using FUSE (as AppImage does), and will need additional space. Think about bundles that are GBs large. |
yeah, depends on your use-case and how big things are i also recently discovered |
According to multiple benchmarks online (like for example: https://www.rootusers.com/gzip-vs-bzip2-vs-xz-performance-comparison/), bzip2 seems to be significantly slower to unpack than gzip and lzma. gzip would be the fastest but doesn't have good compression ratio. |
I think this would require a custom archiver that can bootstrap lz4 decompression
The text was updated successfully, but these errors were encountered: