Relative metadata pointers for reflection records?

I've been talking to a lot of the vapor folks and eventually we always talk about how Mirror is slow. Some of them have done benchmarks and have found that a lot of the work is just in demangling member types in the field records.

Could it be possible to emit relative metadata pointers for member types who are not generic? (Non-generic type metadata is always statically emitted no? or are there other cases?) Is this far fetched? Perhaps a flag to indicate this is a mangled type name or a metadata pointer? I'm sure there's some other reason why this can't be the case, but I'm curious to hear that answer if any.

1 Like

Huge +1 to this. Reflection for better or for worse is a fundamental part of creating enticing web frameworks. And Swift's current solution is relatively slow. From what I can tell in benchmarking, Mirror accounts for ~50% of CPU work being done in our ORM for basic CRUD operations.

1 Like

In the master branch, mangled names now always use direct references to nominal type descriptors, which should already make demangling much faster since it should never fall back to lookup by name. I also plan to introduce a mangling form to refer directly to a metadata record as well, but this will need to be deployment-target-gated. Regardless, though, reflection libraries should probably cache the layout information they decode; that's what SwiftUI does the first time it scans a view type.