Warm up time for generic mapping takes minutes due to the reflection

[Aquathing]

Our codebase heavily relies on Mapperly to map API answers and SQL projections.

We have noticed that the response time for the first request was taking considerabily long (even minutes!), and found Mapperly's generic mapping method to be the problem.

public static partial IQueryable<TResult> QueryAs<T, TResult>(this IQueryable<T> queryable);

The generated code uses a lot of reflection, which I believe has to warm up the reflection metadata for every mapped class (this is my guess) the first time it is used.

Does anybody have any suggestions on how to improve this? Unfortunately, a pre-warmup of this data by calling it before initialization is out of discussion :(

Thanks!

[latonz]

Thanks for reporting. I have never measured this.
Can you share the generated mapping code? Does it behave similarly if you write the mapping code by hand as you would write it intentionally? Does it behave similarly if you use non-generic mapping methods? (e.g:

public static partial IQueryable<MyQueryResult> QueryAs(this IQueryable<MyEntity> queryable);

)?

[Aquathing]

Thanks for reporting. I have never measured this.

It is actually pretty hard to measure too. My first instict was to use dotProfiler, but couldn't find the reason, so I used the step-by-step debugger, and there I noticed that after entering inside the QueryAs method, the debugger would wait for a long time before actually entering the method.

Can you share the generated mapping code?

I have to ask, but it's a big switch with lots (hundreds) of typeof(Type).IsAssignableFrom, exactly like your example code here: #1285 (comment)

Does it behave similarly if you use non-generic mapping methods?

No, in that case, the mapping works without issues.

[Aquathing]

Unfortunately we can't do this because our codebase requires that one MyEntity can have multiple MyQueryResult, and the compiler doesn't know how to differenciate between these two:

public static partial IQueryable<MyQueryResult> QueryAs(this IQueryable<MyEntity> queryable);
public static partial IQueryable<MySecondCallerResult> QueryAs(this IQueryable<MyEntity> queryable);

as it complains that the method definition is the same and the partial method cannot have multiple definitions.

I also tried doing this:

    public static partial IQueryable<TResult> QueryAs<TResult, T>(IQueryable<T> query)
        where TResult : ConcreteTargetType
        where T : ConcreteSourceType;

But unfortunately the method signature is the same so the error is the same as above.

[latonz]

In this case you need to use different method names as a workaround...

[Aquathing]

Yep, unfortunately that is a problem, as it requires a bit of codebase overhaul 😅.

Thanks for your help anyways!

If you need any help testing, please let me know.

[latonz]

I haven’t found the time yet to investigate, but does the same problem occur when compiled with AOT?

[Aquathing]

Yes, I tested that too.