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
{{ message }}
Repository navigation
Thoughts on CryptoKeyLab: Evolving from Reflection to Source Generators for .NET 9 Performance
#7
I’ve been checking out the CryptoKeyLab repository, and I think the concept of a unified Cryptography-as-a-Service gateway built on .NET 9 is awesome. Managing sub-millisecond execution times while targeting over 115 algorithms is a massive goal, and the Clean Architecture setup looks super solid.
Since the project is currently a work in progress and more algorithms are actively being added, I wanted to start a discussion about the core engine's scaling strategy before the architecture gets entirely locked down.
Right now, the platform uses a Reflection-based Factory pattern to dynamically load algorithms at runtime based on database metadata. This is great for keeping things flexible and adhering to the Open-Closed Principle. However, as the project grows and handles heavy enterprise microservice workloads, runtime reflection can become a bottleneck due to CPU overhead and memory allocations that trigger garbage collection.
Have you considered experimenting with .NET 9 Source Generators instead?
Shifting the algorithm registration from runtime reflection to compile-time generation could bring some massive benefits early on:
Zero-Allocation Resolution: It would completely eliminate the runtime overhead of looking up primitives.
Native AOT Ready: It makes the engine fully compatible with Native AOT compilation, making Docker containers or WebAssembly playground builds significantly lighter and faster.
Simpler Contribution Workflow: As new algorithms are added during this WIP phase, source generators could automatically map them without relying on heavy dynamic lookups.
I’d love to know your thoughts on the performance roadmap, and if this is a direction you'd be open to exploring. If it aligns with your vision, I’d be glad to help prototype a proof-of-concept or brainstorm how to bridge compile-time generation with the database metadata layer.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Hey everyone,
I’ve been checking out the CryptoKeyLab repository, and I think the concept of a unified Cryptography-as-a-Service gateway built on .NET 9 is awesome. Managing sub-millisecond execution times while targeting over 115 algorithms is a massive goal, and the Clean Architecture setup looks super solid.
Since the project is currently a work in progress and more algorithms are actively being added, I wanted to start a discussion about the core engine's scaling strategy before the architecture gets entirely locked down.
Right now, the platform uses a Reflection-based Factory pattern to dynamically load algorithms at runtime based on database metadata. This is great for keeping things flexible and adhering to the Open-Closed Principle. However, as the project grows and handles heavy enterprise microservice workloads, runtime reflection can become a bottleneck due to CPU overhead and memory allocations that trigger garbage collection.
Have you considered experimenting with .NET 9 Source Generators instead?
Shifting the algorithm registration from runtime reflection to compile-time generation could bring some massive benefits early on:
Zero-Allocation Resolution: It would completely eliminate the runtime overhead of looking up primitives.
Native AOT Ready: It makes the engine fully compatible with Native AOT compilation, making Docker containers or WebAssembly playground builds significantly lighter and faster.
Simpler Contribution Workflow: As new algorithms are added during this WIP phase, source generators could automatically map them without relying on heavy dynamic lookups.
I’d love to know your thoughts on the performance roadmap, and if this is a direction you'd be open to exploring. If it aligns with your vision, I’d be glad to help prototype a proof-of-concept or brainstorm how to bridge compile-time generation with the database metadata layer.
Kudos on the great work so far!
All reactions