38 lines
1.8 KiB
Plaintext
38 lines
1.8 KiB
Plaintext
* Local (eg DbContext.Books.Local): indexes/hashes PK and nothing else. Local.Find(PK) is fast. All other searches (eg FirstOrDefault) have awful performance. It deceptively *feels* like we get this partially for free since added/modified entries live here.
|
|
* live db: for all importers, fields used for lookup are indexed
|
|
|
|
Using BookImporter as an example: since AudibleProductId is indexed, hitting the live db is much faster than using Local. Fastest is putting all in a local hash table
|
|
|
|
Note: GetBook/GetBooks eager loads Series, category, et al
|
|
|
|
for 1,200 iterations
|
|
* load to LocalView
|
|
DbContext.Books.Local.FirstOrDefault(p => p.AudibleProductId == item.DtoItem.ProductId)
|
|
27,125 ms
|
|
* read from live db
|
|
DbContext.Books.GetBook(item.DtoItem.ProductId)
|
|
12,224 ms
|
|
* load to hash table: Dictionary<string, Book>
|
|
dictionary[item.DtoItem.ProductId];
|
|
1 ms (yes: ONE)
|
|
|
|
With hashtable, somehow memory usage was not significantly affected
|
|
|
|
-----------------------------------
|
|
|
|
why were we using Local to begin with?
|
|
|
|
articles suggest loading to Local with
|
|
context.Books.Load();
|
|
this loads this table but not associated fields
|
|
we want Books and associated fields
|
|
context.Books.GetBooks(b => remainingProductIds.Contains(b.AudibleProductId)).ToList();
|
|
this is emulating Load() but with also getting associated fields
|
|
from: Microsoft.EntityFrameworkCore.EntityFrameworkQueryableExtensions
|
|
// Summary:
|
|
// Enumerates the query. When using Entity Framework, this causes the results of
|
|
// the query to be loaded into the associated context. This is equivalent to calling
|
|
// ToList and then throwing away the list (without the overhead of actually creating
|
|
// the list).
|
|
public static void Load<TSource>([NotNullAttribute] this IQueryable<TSource> source);
|