Fix TimeZoneInfo Perf #85615
Fix TimeZoneInfo Perf #85615
Conversation
|
Tagging subscribers to this area: @dotnet/area-system-datetime Issue DetailsFixes #85432 This issue is addressing multiple performance issues: The first problem arises when creating a TimeZoneInfo object with an alternative zone ID (like using IANA Id on Windows and Windows Id on Linux) using the FindSystemTimeZoneById method. By default, the object returned by GetSystemTimeZones is cached only for the zone ID that matches the OS we are running on. Thus, when we try to create a new object with an alternative ID, we cannot benefit from the cache, and we always attempt to read the zone from the system. On non-Windows OS, this requires accessing the file system and probing for the zone file. To address this issue, we introduce a cache for the alternative ID. The second issue concerns the unnecessary creation of new zone objects when requesting them with FindSystemTimeZoneById. Even if we have already created the object and cached it, we still create a new one every time. However, since the zone objects do not have writable properties, there is no need to clone them. Instead, we can return the cached object to avoid the allocation and the validation of the new object. WindowsBeforeAfterLinuxBeforeAfter
|
|
@stephentoub could you please help review this one? Thanks! |
src/libraries/System.Private.CoreLib/src/System/TimeZoneInfo.cs
Outdated
Show resolved
Hide resolved
ghost
locked as resolved and limited conversation to collaborators
2 participants
Fixes #85432
This change is addressing multiple performance issues:
The first problem arises when creating a TimeZoneInfo object with an alternative zone ID (like using IANA Id on Windows and Windows Id on Linux) using the FindSystemTimeZoneById method. By default, the object returned by GetSystemTimeZones is cached only for the zone ID that matches the OS we are running on. Thus, when we try to create a new object with an alternative ID, we cannot benefit from the cache, and we always attempt to read the zone from the system. On non-Windows OS, this requires accessing the file system and probing for the zone file. To address this issue, we introduce a cache for the alternative ID.
The second issue concerns the unnecessary creation of new zone objects when requesting them with FindSystemTimeZoneById. Even if we have already created the object and cached it, we still create a new one every time. However, since the zone objects do not have writable properties, there is no need to clone them. Instead, we can return the cached object to avoid the allocation and the validation of the new object.
Windows
Before
After
Linux
Before
After