Efcore: Query: Inline shapers for the cases when we don't need variables

[smitpatel]

C# (queryContext, dataReader, resultContext, resultCoordinator) => { Customer namelessParameter{0}; namelessParameter{0} = { MaterializationContext materializationContext1; IEntityType entityType1; Customer instance1; InternalEntityEntry entry1; bool hasNullKey1; materializationContext1 = new MaterializationContext( ValueBuffer, queryContext.Context ); instance1 = null; entry1 = queryContext.TryGetEntry( key: Key: Customer.CustomerID PK, keyValues: new object[]{ try { (object)dataReader.GetString(0) } catch (Exception) { ... } }, throwOnNullKey: True, hasNullKey: hasNullKey1); !(hasNullKey1) ? entry1 != default(InternalEntityEntry) ? { entityType1 = entry1.EntityType; return instance1 = (Customer)entry1.Entity; } : { ValueBuffer shadowValueBuffer1; shadowValueBuffer1 = ValueBuffer; entityType1 = EntityType: Customer; instance1 = switch (entityType1) { case EntityType: Customer: { return { Customer instance; instance = new Customer( materializationContext1.Context, InfrastructureExtensions.GetService<ILazyLoader>((IInfrastructure<IServiceProvider>)materializationContext1.Context), try { dataReader.GetString(0) } catch (Exception) { ... } ); instance.Context = (materializationContext1.Context as NorthwindContext); instance.<Address>k__BackingField = dataReader.IsDBNull(1) ? default(string) : try { dataReader.GetString(1) } catch (Exception) { ... } ; instance.<City>k__BackingField = dataReader.IsDBNull(2) ? default(string) : try { dataReader.GetString(2) } catch (Exception) { ... } ; instance.<CompanyName>k__BackingField = dataReader.IsDBNull(3) ? default(string) : try { dataReader.GetString(3) } catch (Exception) { ... } ; instance.<ContactName>k__BackingField = dataReader.IsDBNull(4) ? default(string) : try { dataReader.GetString(4) } catch (Exception) { ... } ; instance.<ContactTitle>k__BackingField = dataReader.IsDBNull(5) ? default(string) : try { dataReader.GetString(5) } catch (Exception) { ... } ; instance.<Country>k__BackingField = dataReader.IsDBNull(6) ? default(string) : try { dataReader.GetString(6) } catch (Exception) { ... } ; instance.<Fax>k__BackingField = dataReader.IsDBNull(7) ? default(string) : try { dataReader.GetString(7) } catch (Exception) { ... } ; instance.<Phone>k__BackingField = dataReader.IsDBNull(8) ? default(string) : try { dataReader.GetString(8) } catch (Exception) { ... } ; instance.<PostalCode>k__BackingField = dataReader.IsDBNull(9) ? default(string) : try { dataReader.GetString(9) } catch (Exception) { ... } ; instance.<Region>k__BackingField = dataReader.IsDBNull(10) ? default(string) : try { dataReader.GetString(10) } catch (Exception) { ... } ; return instance; }; } default: null } ; entry1 = entityType1 == default(IEntityType) ? default(InternalEntityEntry) : queryContext.StartTracking( entityType: entityType1, entity: instance1, valueBuffer: shadowValueBuffer1); return instance1; } : default(void); return instance1; }; return namelessParameter{0}; }
Currently, we generate shaper like above for a simple query like context.Customers.ToList().
Point to notice is the introduction of variables. We do this since we don't want to materialize same entity instance multiple times if it is being referenced multiple times in the projection. (this is all true only when there are no collection to be materialized, which has different structure for shaper). It also helps for a column being read from server if the column is something like binary which could have large size.

For scenarios where each ProjectionBindingExpression is being used only once and there are no collection, we can inline the operations without introducing variables.
An additional perf benefit would be that if the statement contains condition ? EntityA : EntityB then we could skip materializing one entity altogether based on how condition evaluates.

[roji]

For scenarios where each ProjectionBindingExpression is being used only once and there are no collection, we can inline the operations without introducing variables.

Keep in mind that the JIT ends up optimizing this, so removing a temporary variable isn't likely to have any perf impact.

An additional perf benefit would be that if the statement contains condition ? EntityA : EntityB then we could skip materializing one entity altogether based on how condition evaluates.

That could impactful for sure.

[ajcvickers]

@roji I've heard that JIT performs fewer optimizations on dynamically generated code. Do you know if this is true and, if so, to what extent it applies?

[roji]

@ajcvickers I admit I don't know anything about specific JIT behavior around generated code... That's interesting. I can't quite see why there would be a difference - but it's very easy to benchmark and verify specific scenarios like this one.

[ajcvickers]

@roji I may be wrong--it might just not be getting compiler optimizations (obviously.) It was something Diego used to mention and I never asked him about in more detail.