[Enhancement] Add source generator for reflection-based lists #193

New Issue

claunia · 2026-01-29T21:07:02Z

claunia commented

2026-01-29 21:07:02 +00:00

Originally created by @mnadareski on GitHub (Feb 24, 2025).

Originally assigned to: @mnadareski on GitHub.

Instead of relying on reflection to build things like the lists of types that can be used for each method, a source generator should be implemented that will generate those lists statically at build.

This should be explored because the overhead of reflection is fairly substantial compared to hardcoded lists. Maintaining those hardcoded lists can take a lot of effort and can drift from implementations more easily. The other downside to reflection is that it is not AOT-compatible. This means that native libraries cannot be compiled in any of those cases.

This may necessitate changes even further down the chain, so this item may be a parent item for other changes later.

Originally created by @mnadareski on GitHub (Feb 24, 2025). Originally assigned to: @mnadareski on GitHub. Instead of relying on reflection to build things like the lists of types that can be used for each method, a source generator should be implemented that will generate those lists statically at build. This should be explored because the overhead of reflection is fairly substantial compared to hardcoded lists. Maintaining those hardcoded lists can take a lot of effort and can drift from implementations more easily. The other downside to reflection is that it is not AOT-compatible. This means that native libraries cannot be compiled in any of those cases. This may necessitate changes even further down the chain, so this item may be a parent item for other changes later.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: SabreTools/BinaryObjectScanner#193