Repository navigation
Users benefit from faster runtime startup due to reductions in runtime startup overhead #44598
Copy link
Copy link
Closed
Labels
Cost:MWork that requires one engineer up to 2 weeksWork that requires one engineer up to 2 weeksPriority:1Work that is critical for the release, but we could probably ship withoutWork that is critical for the release, but we could probably ship withoutTeam:RuntimeUser StoryA single user-facing feature. Can be grouped under an epic.A single user-facing feature. Can be grouped under an epic.area-Metatenet-performancePerformance related issuePerformance related issue
Milestone
Description
.NET processes are spun up repeatedly as part of a developer's inner loop development process, including for the app itself being debugged. We want to drive down the overheads across all tools employed as part of inner loop, and that includes reducing runtime startup costs wherever possible.
Issues:
- TPA list building is contributing large % of time to startup
- Environment.GetEnvironmentVariables() called multiple times during MVC app startup
- Implement EventSource generator
- Speed up type loading with R2R images
- Remove unnecessary regex from ASP.NET startup
- Improve startup time for EventSources
- Avoid EventSource contention at startup
- Exception performance with debugger attached
- Eliminate low-hanging fruit in Hello, World startup
- Allocations in Hello, World from Console.Write
- Allocations in ManifestBuilder.CreateManifestString in EventSource startup
- Closure allocations from ServiceCollectionDescriptorExtensions at MVC startup
- Allocations from GetCustomAttributes impacting MVC startup
- Avoiding LINQ overheads in JsonConfiguration
- Avoiding string-related allocation in LogValuesFormatter ctor during startup
- Reduce Process.Start overhead
- Avoid allocations in LoggerRuleSelector in MVC startup
- Avoid CallSiteFactory allocations in MVC startup
- Avoid empty ParameterInfo[] allocations at startup
- Avoid string concats in CreateDefaultLogMessage
- Remove most LINQ usage from Microsoft.Extensions.Configuration
- Avoid expensive CertificateManager work when it's not enabled
- Reduce Guid parsing times during startup
- Avoid LINQ usage in EnvironmentVariablesConfigurationProvider
- Improve throughput of GetEnvironmentVariables
- Skip invariant init test for Invariant
- Reduce MakeGenericType overhead impacting startup
- Reduce SafeHandles created enumerating certificates at startup
- Remove allocations from ObjectCache
- Reduce allocations in OptionsManager at startup
- Remove closure/delegate allocations from CreateLogger
- Improve OidLookup.ToLookup perf
- Reduce allocation in BigInteger used to process certificates
- Improve EventSource attribute lookup during ctor
- Remove more LINQ from dependency injection
- Remove boxing from configuration loading
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Cost:MWork that requires one engineer up to 2 weeksWork that requires one engineer up to 2 weeksPriority:1Work that is critical for the release, but we could probably ship withoutWork that is critical for the release, but we could probably ship withoutTeam:RuntimeUser StoryA single user-facing feature. Can be grouped under an epic.A single user-facing feature. Can be grouped under an epic.area-Metatenet-performancePerformance related issuePerformance related issue
Type
Projects
- StatusShow more project fieldsDone
Activity
Dotnet-GitSync-Bot commentedon Nov 12, 2020
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.
iSazonov commentedon Nov 26, 2020
I measured PowerShell startup. It seems there are delays in hostpolicy on realpath() and GetFileAttributesExW().


I hope performance improvements could be made there. (Is it really necessary to check for the existence of files?)
PerfView trace https://ru.files.fm/u/n2hqqsr7z
jkotas commentedon Nov 26, 2020
@iSazonov This is tracked by #44545
[-]Reduce the overhead incurred when starting up the runtime[/-][+]Users benefit from faster runtime startup due to reductions in runtime startup overhead[/+]stephentoub commentedon Jul 6, 2021
All planned work for .NET 6 has been done here, with some nice improvements on startup. I'm going to close this; there can still be further opportunistic work for the release.