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

Analysis of gnmic dependencies to reduce binary size #577

Open
RonanMacF opened this issue Jan 6, 2025 · 1 comment
Open

Analysis of gnmic dependencies to reduce binary size #577

RonanMacF opened this issue Jan 6, 2025 · 1 comment

Comments

@RonanMacF
Copy link

Hi, I am a big fan of this tool and would like to include it, however, my project is space sensitive and gnmic taking upwards of 100MB is quite a lot.

I am wondering if there has been any consideration into making a leaner client, or perhaps making the current client leaner. For example, the dependency github.com/hairyhenderson/gomplate/v3 seems to be used for input parsing. This dependency brings in github.com/aws/aws-sdk-go-v2/* dependencies which increase the size of the binary by ~30MB.

Similarly optionally including lockers would allow us to leave the k8 dependency out which would also save ~30MB.

I am considering forking this repo and chopping this stuff out to reduce size, which would get it below 50MB with not a massive amount of work (alberit the input parsing would have to be rewritten). I would rather contribute to upstream for the communities benefit and so am wondering if something like this has been considered?

@karimra
Copy link
Collaborator

karimra commented Jan 6, 2025

Hi, this came up a couple of times.
There are two options to get a smaller binary:

  1. Build a thin version of the client, removing most outside dependencies and "fancy" functionalities. This will made building and testing a bit more complicated but more importantly: Where do we draw the line between basic and "fancy" functionalities.
  2. Decouple some of the functionalities as plugins. It adds the overhead of managing the plugins life cycle.
    Here there are two options as well:
    2.a) Use Golang's plugin package (this can create a dependency nightmare)
    2.b) Use HC go-plugin. This is already used for the processor plugin but it comes with a performance hit. So it cannot be used for any functionality.

I did some tests for 2.a) and taking out the gomplate deps as a plugin. It did save the same 30MB, but using the plugin package adds a 20MB to the final size (even if it's part of the stdlib). So it's really only valuable if a few functionalities use it.
I will see if I can move the locker package as a plugin.

I understand the issue with the size, but there is also value in having a single binary that you can copy anywhere without having to worry about dependencies.

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

No branches or pull requests

2 participants