fix: restore timing, bound parallelism, stabilize output ordering in view generation#2
Merged
Merged
Conversation
…nsure deterministic view ordering Agent-Logs-Url: https://github.com/Raylopi/ef6/sessions/d872e6fc-716c-4129-85db-5ccf24cc2577 Co-authored-by: Raylopi <54796610+Raylopi@users.noreply.github.com>
Copilot
AI
changed the title
[WIP] Optimize EF6 view generation for databases with 500+ tables
fix: restore timing, bound parallelism, stabilize output ordering in view generation
Apr 3, 2026
Raylopi
approved these changes
Apr 3, 2026
Raylopi
added a commit
that referenced
this pull request
Apr 3, 2026
… view generation Implement Parte 1 of Issue #2: Public API in StorageMappingItemCollection that generates views for a subset of entity sets (cell groups) only. Changes: - Add StorageMappingItemCollection.GenerateViewsIncremental(ISet<string> entitySetNamesToRegenerate, IList<EdmSchemaError> errors) public method Returns IReadOnlyDictionary<EntitySetBase, DbMappingView> containing ONLY views of regenerated groups. Caller responsible for merging with cached views. - Add ViewgenGatekeeper.GenerateViewsFromMappingIncremental() entry point - Add optional entitySetNameFilter parameter to GenerateViewsFromCells() After CellPartitioner groups cells, filters to keep only groups that contain at least one extent whose name is in entitySetNameFilter. All validation (CellGroupValidator, FK constraints) still runs on regenerated groups. Architecture: - If entitySetNameFilter is null: generates all views (backward compatible) - If entitySetNameFilter has names: expands to full cell groups via FK/entity-split graph and regenerates only those groups - Returns only views for changed entity sets (VSIX merges with cache) Integration point for VSIX incremental generation: VSIX calls via reflection to check if GenerateViewsIncremental exists, uses it if available with delta-detected entity sets, falls back to full GenerateViews() on EF6 stock or if method absent. Expected impact: On a model with 500+ tables where only 3 entities changed, regenerates only the affected cell groups instead of all ~20 groups, reducing view gen time from 6+ minutes to <10 seconds.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The existing parallelization of EF6 view generation (OPT-1/2/3) had three defects introduced during the refactor.
Fixes
Missing timing in sequential path —
SetTimeForFinishedActivitywas removed fromGenerateDirectionalViewsForExtentand only restored in the parallel branch. The sequential fallback (GenerateDirectionalViewsSequential, hit when extent count ≤ 1) never recordedPerfType.QueryViews/UpdateViewstiming.Unbounded parallelism — Both
Parallel.ForEachcalls (cell groups inViewgenGatekeeper, extents inViewGenerator) used default scheduler with no degree limit, risking ThreadPool saturation under hosted contexts (IIS, VS). AddedMaxDegreeOfParallelism = Environment.ProcessorCount.Non-deterministic output ordering —
ConcurrentBagenumeration order is arbitrary. PowerTools serializes the view dictionary to a.csfile, so unstable ordering causes spurious diffs. Views are now sorted byEntitySetBase.Name(ordinal) before merge.Files changed
ViewGenerator.cs— all three fixesViewgenGatekeeper.cs— parallelism bound + orderingWarning
Firewall rules blocked me from connecting to one or more addresses (expand for details)
I tried to connect to the following addresses, but was blocked by firewall rules:
pdfvsblobprodcus380.vsblob.vsassets.io/usr/bin/dotnet dotnet restore EntityFramework.sln(dns block)/usr/bin/dotnet dotnet build src/EntityFramework/EntityFramework.csproj -f netstandard2.1 --no-restore(dns block)uy6vsblobprodcus34.vsblob.vsassets.io/usr/bin/dotnet dotnet build src/EntityFramework/EntityFramework.csproj -f netstandard2.1 --no-restore(dns block)If you need me to access, download, or install something from one of these locations, you can either: