System.Tests.Perf_DateTime.GetNow gets slower every summer due to daylight savings #67932

Activity

1. dakersnar

   added

   tenet-performancePerformance related issuePerformance related issue

   on Apr 12, 2022
3. ghost added

   untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

   on Apr 12, 2022
4. EgorBo commented on Apr 12, 2022

   

   EgorBo

   on Apr 12, 2022

   Member

   More actions

   This is expected, DateTime.Now regresses and improves once a year at fixed dates due to DST ;-) https://twitter.com/EgorBo/status/1460697206667763714

   😄React with 😄3Reacted by Clinton Ingram, Drew Kersnar and Jeff Handley
5. danmoseley commented on Apr 12, 2022

   

   danmoseley

   on Apr 12, 2022

   Last edited by danmoseley

   Contributor

   More actions

   this code only runs when we're in DST: https://github.com/dotnet/runtime/blob/67761043f1b0e1514a1b8c1c6d99a353737a24a1/src/libraries/System.Private.CoreLib/src/System/TimeZoneInfo.cs#L1383-L1412

   But, that doesn't seem like much. would need profiling.
6. EgorBo commented on Apr 12, 2022

   

   EgorBo

   on Apr 12, 2022

   Last edited by EgorBo

   Member

   More actions

   @danmoseley I don't think it executes that code as part of DateTime.Now, I assume the regression is internal in kernel32
7. EgorBo commented on Apr 12, 2022

   

   EgorBo

   on Apr 12, 2022

   Member

   More actions

   oh, or maybe it does?
   
8. danmoseley commented on Apr 13, 2022

   

   danmoseley

   on Apr 13, 2022

   Last edited by danmoseley

   Contributor

   More actions

   Is that with DST, or without? If GetDatePart is larger in DST, then it's perhaps because it's getting Year out of the DateTime in that block. The code before already gets Day and Month and Year, though. I wonder if there is opportunity to have GetDatePart() return all of those together rather than repeat its work. (Edit - I see that's GetDate())

   is the codegen for GetDatePart() reasonable?
9. EgorBo commented on Apr 13, 2022

   

   EgorBo

   on Apr 13, 2022

   Member

   More actions

   Ah, ignore my flamegraph - it's for my local time where we don't have daylight savings. When I change my tz to the pacific one I now see a different picture - it seems there are quite a few things to optimize
   

   is the codegen for GetDatePart() reasonable?

   more or less, but we might need to extract it for Year separately since it's on a hot path and inline into Year property.
   Also, it's executed from 3 different places in this flamegraph
10. EgorBo

    added this to the 7.0.0 milestone on Apr 13, 2022
11. EgorBo

    added

    area-System.Runtime

    on Apr 13, 2022
13. EgorBo

    self-assigned this

    on Apr 13, 2022
14. EgorBo commented on Apr 13, 2022

    

    EgorBo

    on Apr 13, 2022

    Member

    More actions

    I'll take a look when I have some spare time 🙂
15. EgorBo

    modified the milestones: 7.0.0, Future on Apr 13, 2022
16. ghost removed

    untriagedNew issue has not been triaged by the area ownerNew issue has not been triaged by the area owner

    on Apr 13, 2022
17. danmoseley

    added

    help wanted[up-for-grabs] Good issue for external contributors[up-for-grabs] Good issue for external contributors

    on Aug 16, 2022
18. danmoseley

    changed the title [-]System.Tests.Perf_DateTime.GetNow has regressed across multiple configurations[/-] [+]System.Tests.Perf_DateTime.GetNow gets slower every summer due to daylight savings[/+] on Aug 17, 2022
19. danmoseley commented on Aug 20, 2022

    

    danmoseley

    on Aug 20, 2022

    Last edited by danmoseley

    Contributor

    More actions

    I measured the impact locally, including old frameworks for interest. Difference is only about 4% now, in .NET 6 it was 9% which is what the graph above shows from earlier. The recent #72712 will have contributed to that, because the DST path adds calls to Year, Month, Day.

    @tarekgh it is OK to assume that timezone rules aren't changing during the lifetime of the process, right? So possibly the current rule and timezone can be cached, and if the timezone matches what was cached, we can continue to use that rule, and maybe short circuit simple cases. I'll leave as help wanted in case someone wants to take a look at some kind of caching of that sort. But otherwise I am not sure it is worth further attention.

    BenchmarkDotNet=v0.13.1, OS=Windows 10.0.19044.1889 (21H2)
    Intel Core i7-7700 CPU 3.60GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
    .NET SDK=7.0.100-rc.2.22419.24
      [Host]     : .NET 7.0.0 (7.0.22.41112), X64 RyuJIT
      Job-CERAHN : .NET 8.0.0 (42.42.42.42424), X64 RyuJIT
      Job-SZEXDU : .NET 6.0.8 (6.0.822.36306), X64 RyuJIT
      Job-BHYKGQ : .NET Core 3.1.28 (CoreCLR 4.700.22.36202, CoreFX 4.700.22.36301), X64 RyuJIT
      Job-NYWNMR : .NET Framework 4.8 (4.8.4510.0), X64 RyuJIT
    
    
    |            Method |        Job |            Runtime |                                Toolchain |      Mean |    Error |   StdDev | Ratio | RatioSD | Allocated |
    |------------------ |----------- |------------------- |----------------------------------------- |----------:|---------:|---------:|------:|--------:|----------:|
    | DateTimeNow_NoDST | Job-CERAHN |           .NET 7.0 |                        \main\corerun.exe |  81.67 ns | 1.479 ns | 1.311 ns |  1.00 |    0.00 |         - |
    |   DateTimeNow_DST | Job-CERAHN |           .NET 7.0 |                        \main\corerun.exe |  85.09 ns | 0.479 ns | 0.448 ns |  1.04 |    0.02 |         - |
    | DateTimeNow_NoDST | Job-SZEXDU |           .NET 6.0 |                                  Default |  94.49 ns | 0.640 ns | 0.567 ns |  1.16 |    0.02 |         - |
    |   DateTimeNow_DST | Job-SZEXDU |           .NET 6.0 |                                  Default | 103.12 ns | 0.512 ns | 0.479 ns |  1.26 |    0.02 |         - |
    | DateTimeNow_NoDST | Job-BHYKGQ |      .NET Core 3.1 |                                  Default | 215.65 ns | 1.004 ns | 0.890 ns |  2.64 |    0.05 |         - |
    |   DateTimeNow_DST | Job-BHYKGQ |      .NET Core 3.1 |                                  Default | 226.76 ns | 1.080 ns | 0.902 ns |  2.78 |    0.04 |         - |
    | DateTimeNow_NoDST | Job-NYWNMR | .NET Framework 4.8 |                                  Default | 217.80 ns | 0.855 ns | 0.800 ns |  2.67 |    0.04 |         - |
    |   DateTimeNow_DST | Job-NYWNMR | .NET Framework 4.8 |                                  Default | 229.96 ns | 0.847 ns | 0.751 ns |  2.82 |    0.04 |         - |
    

    benchmark

    using System;
    using System.ComponentModel;
    using System.Runtime.InteropServices;
    using BenchmarkDotNet.Attributes;
    using BenchmarkDotNet.Configs;
    using BenchmarkDotNet.Environments;
    using BenchmarkDotNet.Jobs;
    using BenchmarkDotNet.Running;
    
    [MemoryDiagnoser]
    public class Program
    {
        // run as admin 
        public static void Main(string[] args)
        {
            var config = DefaultConfig.Instance
            .AddJob(Job.Default.WithRuntime(CoreRuntime.Core31))
            .AddJob(Job.Default.WithRuntime(CoreRuntime.Core60))
            .AddJob(Job.Default.WithRuntime(CoreRuntime.CreateForNewVersion("net7.0", ".NET 7.0")))
            .AddJob(Job.Default.WithRuntime(ClrRuntime.Net48));
            BenchmarkSwitcher.FromAssembly(typeof(Program).Assembly).Run(args, config);
        }
    
        [GlobalSetup(Target = nameof(DateTimeNow_NoDST))]
        public void NoDST() => SetSystemTime(new DateTime(2022, 12, 1)); // assuming US
    
        [GlobalSetup(Target = nameof(DateTimeNow_DST))]
        public void DST() => SetSystemTime(new DateTime(2022, 6, 1)); // assuming US
    
        [Benchmark(Baseline = true)]
        public DateTime DateTimeNow_NoDST() => DateTime.Now;
    
        [Benchmark]
        public DateTime DateTimeNow_DST() => DateTime.Now;
    
        public void SetSystemTime(DateTime dt)
        {
            SYSTEMTIME st = new SYSTEMTIME();
            st.wYear = (short)dt.Year;
            st.wMonth = (short)dt.Month;
            st.wDay = (short)dt.Day;
            SetSystemTime(ref st);
            int errorCode = Marshal.GetLastWin32Error();
            if (errorCode != 0)
                throw new Win32Exception(errorCode);
        }
        [DllImport("kernel32.dll", SetLastError = true)]
        private static extern bool SetSystemTime(ref SYSTEMTIME st);
    }
    
    [StructLayout(LayoutKind.Sequential)]
    public struct SYSTEMTIME
    {
        public short wYear;
        public short wMonth;
        public short wDayOfWeek;
        public short wDay;
        public short wHour;
        public short wMinute;
        public short wSecond;
        public short wMilliseconds;
    }

    Here's an idea of where the time is spent. There's not a clear "single place".
    
20. tarekgh commented on Aug 20, 2022

    

    tarekgh

    on Aug 20, 2022

    Last edited by tarekgh

    Member

    More actions

    it is OK to assume that timezone rules aren't changing during the lifetime of the process, right?

    Not really, users can change the local time zone and clear the cached Local TZ. But we can handle flushing the current rule if the local TZ cache is flushed. By the way, on Windows, we already cache the rule

    runtime/src/libraries/System.Private.CoreLib/src/System/TimeZoneInfo.Win32.cs

    Line 374 in 6d60d06

    OffsetAndRule match = s_cachedData.GetOneYearLocalFromUtc(timeYear);

    The better idea here is not catching the rule and only cache the UTC offset and when the daylight will change. Doing that will make calculation of the Now much faster and simpler to handle too. I can try that when I get some chance.

    👍React with 👍1Reacted by Dan Moseley
21. danmoseley

    removed

    help wanted[up-for-grabs] Good issue for external contributors[up-for-grabs] Good issue for external contributors

    on Aug 20, 2022
22. jeffhandley

    added

    area-System.DateTime

    and removed

    area-System.Runtime

    on Nov 22, 2022
23. danmoseley

    added

    help wanted[up-for-grabs] Good issue for external contributors[up-for-grabs] Good issue for external contributors

    on May 25, 2023
24. stephentoub commented on Oct 11, 2025

    

    stephentoub

    on Oct 11, 2025

    Member

    More actions

    @tarekgh, is this still relevant with your recent improvements?

    👍React with 👍1Reacted by Tarek Mahmoud Sayed
25. tarekgh commented on Oct 11, 2025

    

    tarekgh

    on Oct 11, 2025

    Member

    More actions

    Yes, this should be addressed by #119662. Thanks @stephentoub for pointing out at this issue.
26. tarekgh

    closed this as completedon Oct 11, 2025
27. github-actions

    locked and limited conversation to collaborators on Nov 11, 2025