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
Right now, mapping event types to classes is done using a dictionary. It requires either to register types explicitly or use assembly scanning and attributes. Assembly scanning works with EventType attribute. Dictionaries are relatively fast, but still slower than direct calls. For example, generic-based type map used to map commands to command handlers is by order of magnitude faster than the event type map.
As most of us use the attribute anyway, it should be possible to generate code for event type mapping, both forwards and backwards (type->name and name->type).
The first step could be eliminating assembly scanning, so Eventuous gets a bit closer to be AOT-compliant. The first iteration could generate code to add types and names to the existing TypeMap without assembly scanning at runtime.
The second step would be to generate a static function with a switch expression to replace the type map. However, it will kill the option to provide custom type maps and having multiple type maps in one application. However, I don't know how many people use that option and if it's useful at all.
Feedback about using multiple type maps within one app would be great.
The text was updated successfully, but these errors were encountered:
Right now, mapping event types to classes is done using a dictionary. It requires either to register types explicitly or use assembly scanning and attributes. Assembly scanning works with
EventType
attribute. Dictionaries are relatively fast, but still slower than direct calls. For example, generic-based type map used to map commands to command handlers is by order of magnitude faster than the event type map.As most of us use the attribute anyway, it should be possible to generate code for event type mapping, both forwards and backwards (type->name and name->type).
The first step could be eliminating assembly scanning, so Eventuous gets a bit closer to be AOT-compliant. The first iteration could generate code to add types and names to the existing
TypeMap
without assembly scanning at runtime.The second step would be to generate a static function with a switch expression to replace the type map. However, it will kill the option to provide custom type maps and having multiple type maps in one application. However, I don't know how many people use that option and if it's useful at all.
Feedback about using multiple type maps within one app would be great.
The text was updated successfully, but these errors were encountered: