You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description
Using excelize in a go binary increases the size by 17 MB. This is by far the biggest dependency in our eco-system. Is there any way to decrease the binary size?
Go Build should remove unneeded parts with dead code analysis. Are there maybe big static tables of strings or other data, which are included in the source code and bloat ob the binary? Maybe they could be moved to a sub-folder or behind build-tags, so users who don't need them can exclude them?
The text was updated successfully, but these errors were encountered:
This could be caused by uses of the reflect package, which for some methods disables dead code analysis because of the compiler not being able to figure out what reflect may want to access.
@paolobarbolini the reflect package has received an update a while ago, where it will not block dead code analysis, if it can determine the strings user as function names at compile time. Maybe some simplification in how the strings for the reflect calls are created could enable the compiler to predict what values will be used?
Are there any other big generated data-structures in the library?
Description
Using excelize in a go binary increases the size by 17 MB. This is by far the biggest dependency in our eco-system. Is there any way to decrease the binary size?
Go Build should remove unneeded parts with dead code analysis. Are there maybe big static tables of strings or other data, which are included in the source code and bloat ob the binary? Maybe they could be moved to a sub-folder or behind build-tags, so users who don't need them can exclude them?
The text was updated successfully, but these errors were encountered: