cmd/compile: unnecessary hash/eq functions for global arrays #30528
Labels
Milestone
Comments
Are you talking about the binary size of the executable? Or the object file? I would think the linker deadcode eliminates the hash/eq functions if they are not called. |
That said, we probably should fix the compiler to not generate them in the first place. |
Definitely object file, not sure about binary. The issue @neild and I were running into was that the linker was OOMing. There are many reasons for an OOM, but one contributor were (presumably) the size of the object file inputs, for which the hash/eq functions were a non-trivial contributor of bloat. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a generalization of the problem described in #30449.
Suppose we have a unexported global variable:
and none of the operations performed on this array:
==
or as a map key)For example, operations like indexing (e.g.,
myArray[3]
) and slicing (e.g.,myArray[:]
) are permitted.If the above conditions are met, I believe that hash/eq functions need not be generated for that array since it is provably not used in the package, and cannot be used dynamically since the array itself does not escape from the package.
The use case for this is code like:
We declare
globalMessageTypes
as an array so that theT.Type
andR.Type
methods do not need a bounds check when indexing into the global array. However, the generated hash/eq functions add significant binary bloat.The workaround to this is to use a global slice instead of an array, but that has other issues (see #30529).
The text was updated successfully, but these errors were encountered: