introduce gzip compression levels fastest, default, best #4

dasimmet commented 2025年12月21日 20:34:08 +01:00

@jeffective what do you think about introducing compression levels?
1-9 seems a bit overkill, but maybe just 3 levels?

@jeffective what do you think about introducing compression levels? 1-9 seems a bit overkill, but maybe just 3 levels?

jeffective commented 2025年12月21日 20:37:19 +01:00

I think we can provide union that exposes all the compression options, and perhaps rename .raw to .none?

I think we can provide union that exposes all the compression options, and perhaps rename `.raw` to `.none`?

jeffective commented 2025年12月21日 20:38:32 +01:00

If the gzip standard people thought 1-9 was useful and the oci standard people thought gzip was good, who am I to argue with it?

If the gzip standard people thought 1-9 was useful and the oci standard people thought gzip was good, who am I to argue with it?

jeffective commented 2025年12月21日 20:43:16 +01:00

I can see that it might make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called makeFn. Not sure how they would but we might consider change from our existing exectuable approach to that?

I can see that it might make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called `makeFn`. Not sure how they would but we might consider change from our existing exectuable approach to that?

dasimmet commented 2025年12月21日 20:52:00 +01:00

@jeffective wrote in #4 (comment):

I can see that is light make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called makeFn. Not sure how they would but we might consider change from our existing exectuable approach to that?

well the "interface" of zigs build system is that in build.zig the data structures of the graph are produced, and then the makeFn is executed afterwards by the build runner and receives the datastructure, hashes all inputs to calculate cache hits & misses, and in case of a miss runs the build.

There's plans to sandbox "build.zig" and then custom "makeFn" might not work anymore. i think the exe approach is more futureproof, but at some point i'd reconsider to create a single binary for all create_ subcommands, because it saves intermediate build steps and disk space.

For building the graph from oci as a dependency, i can try creating another branch with a proof of concept in the "example" subdir if you want

@jeffective wrote in https://codeberg.org/jeffective/oci/pulls/4#issuecomment-9125259: > I can see that is light make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called `makeFn`. Not sure how they would but we might consider change from our existing exectuable approach to that? well the "interface" of zigs build system is that in build.zig the data structures of the graph are produced, and then the makeFn is executed afterwards by the build runner and receives the datastructure, hashes all inputs to calculate cache hits & misses, and in case of a miss runs the build. There's plans to sandbox "build.zig" and then custom "makeFn" might not work anymore. i think the exe approach is more futureproof, but at some point i'd reconsider to create a single binary for all create_ subcommands, because it saves intermediate build steps and disk space. For building the graph from oci as a dependency, i can try creating another branch with a proof of concept in the "example" subdir if you want

dasimmet commented 2025年12月21日 21:02:11 +01:00

@jeffective wrote in #4 (comment):

I can see that it might make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called makeFn. Not sure how they would but we might consider change from our existing exectuable approach to that?

also i think the build runner running "makeFn" is always compiled in debug mode, and the compression is a lot faster with release optimizations, which should be the default at some point.

@jeffective wrote in https://codeberg.org/jeffective/oci/pulls/4#issuecomment-9125259: > I can see that it might make the cli parser annoying for the steps, I don't fully understand it but there are these things in the existing zig build system called `makeFn`. Not sure how they would but we might consider change from our existing exectuable approach to that? also i think the build runner running "makeFn" is always compiled in debug mode, and the compression is a lot faster with release optimizations, which should be the default at some point.