Skip to content
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

consider compressing large strings #651

Closed
ee7 opened this issue Aug 6, 2022 · 0 comments · Fixed by #652
Closed

consider compressing large strings #651

ee7 opened this issue Aug 6, 2022 · 0 comments · Fixed by #652
Assignees

Comments

@ee7
Copy link
Member

ee7 commented Aug 6, 2022

It's easy to compress large strings at compile time and uncompress them at run time. This isn't that useful for configlet, but we could compress at least the embedded:

  • help message
  • completion scripts

Right now, this would reduce the binary size by only a couple of percent at best. But it's easy, has few disadvantages, and there may be other good candidates for compression later (at least the zsh and powershell completion scripts). So maybe it's worth doing.

@ee7 ee7 self-assigned this Aug 6, 2022
@ee7 ee7 closed this as completed in #652 Aug 9, 2022
ee7 added a commit that referenced this issue Aug 9, 2022
This uses `supersnappy` [1], which is a zero-dependency pure-Nim
implementation of Google's Snappy [2].

With it, it is straightforward to compress our larger `const` strings
at compile time and uncompress them at run time. For now, this commit
compresses:

- The `configlet --help` message
- The completion scripts

`supersnappy` is less than 500 lines of code, which is why compressing
these strings (which aren't so large) produces a slightly smaller
configlet binary, despite the added dependency.

We may end up adding `zippy` [3] as a dependency if configlet learns
to make network requests (e.g. for the online `configlet lint` checks)
so that we can use gzip. But we can't use `zippy` at compile time, so it
isn't useful for this commit, even though the compression is better.
`zippy` is also a bigger dependency (about 40 KiB), so it wouldn't
produce a net saving for this commit anyway.

`nim-snappy` [4] is an alternative Snappy implementation, but it would
add dependencies [5] on `faststreams`, `unittest2`, and `stew`.

[1] https://github.com/guzba/supersnappy
[2] https://github.com/google/snappy
[3] https://github.com/guzba/zippy
[4] https://github.com/status-im/nim-snappy
[5] https://github.com/status-im/nim-snappy/blob/7cb2e57a5861/snappy.nimble

Closes: #651
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant