Micro-optimization suggestion: Allocate less memory for Stopwatch object on the heap

[ymalich]

The current implementation of the Stopwatch class has the field
private bool _isRunning.

In my opinion, this field is redundant and leads to the allocation of an additional 8 bytes of heap (in 64-bit mode).
Instead of accessing the _isRunning field, it is better to implement the property,

public bool IsRunning => _startTicks > 0;

The trick is that the implementation of the QueryPerformanceCounter() functions for Unix and Windows guarantees that at the moment of calling these functions, the value more then 0 will be saved in the _startTicks variable (otherwise it means the system counters do not work).
Therefore, it is safe to check _startTicks > 0 instead of _isRunning.
And in the Stop() function reset _startTicks = 0.

If no one has any objections, I could change the code and create a pull request to contribute.

I tested the changes in Windows on my side.

[stephentoub]

implementation of the QueryPerformanceCounter() functions for Unix and Windows guarantees that at the moment of calling these functions, the value more then 0

Can you point to where this is documented?

[ymalich]

@stephentoub
Can you point to where this is documented?
https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

Return value

_If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError. On systems that run Windows XP or later, the function will always succeed and will thus never return zero._

[stephentoub]

@stephentoub Can you point to where this is documented? https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

Return value

_If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError. On systems that run Windows XP or later, the function will always succeed and will thus never return zero._

But the value that's used isn't the BOOL that's returned... it's the value pointed to by lpPerformanceCount

[ymalich]

@stephentoub
ok, I made a mistake in quoting this text here, sorry :)

but here
QueryPerformanceCounter reads the performance counter and returns the total number of ticks that have occurred since the Windows operating system was started, including the time when the machine was in a sleep state such as standby, hibernate, or connected standby.

I've made the conclusion - 1 tick later after OS startup the timer will never be 0.
I assumed no .NET application can start right at the time then OS is being initialized. :)

[f2bo]

Stopwatch has a Stop method that presumably would need to clear _startTicks with the proposed change. I haven't looked at the code but will the Elapsed property return the correct value after calling this method once you reset _startTicks?

[stephentoub]

I've made the conclusion - 1 tick later after OS startup the timer will never be 0.

Thanks. Putting aside the assumption for a moment, where is it documented for all of the various functions we might use on Unix?

If this extra 8 bytes of overhead is a problem for someone, they're better off just using Stopwatch.GetTimestamp/GetElapsedTime and not allocating at all. So while I'm interested in trimming fat here if it's 100% guaranteed, I'm not if there's any risk.

[stephentoub]

Stopwatch has a Stop method that presumably would need to clear _startTicks with the proposed change. I haven't looked at the code but will the Elapsed property return the correct value after calling this method once you reset _startTicks?

It keeps track of elapsed separately, as it needs to account for multiple start/stops and accumulating their individual elapsed times.

[hez2010]

Note that if you use Stopwatch without calling Stop, the JIT can inline the Stopwatch usage, allocate it on the stack and then promote the entire stack allocated object to the register, so that it ends up allocating nothing, and _isRunning is completely eliminated:

static void Foo()
{
    var st = new Stopwatch();
    st.Start();
    Console.WriteLine("Running");
    Console.WriteLine(st.ElapsedTicks);
}

The codegen for Foo:

Program:Foo() (FullOpts):
       push     rbp
       push     r15
       push     rbx
       vzeroupper 
       lea      rbp, [rsp+0x10]
       mov      rax, 0x72A59B511560      ; function address
       call     rax ; Interop+Sys:GetTimestamp():ulong
       mov      rbx, rax
       mov      rdi, 0x72A596602D10      ; 'Running'
       call     [System.Console:WriteLine(System.String)]
       mov      rax, 0x72A59B511560      ; function address
       call     rax ; Interop+Sys:GetTimestamp():ulong
       mov      r15, rax
       sub      r15, rbx
       cmp      dword ptr [(reloc 0x72a59b1a7820)], 0
       jne      SHORT G_M24659_IG07
G_M24659_IG05:  ;; offset=0x0046
       mov      rdi, r15
       pop      rbx
       pop      r15
       pop      rbp
       tail.jmp [System.Console:WriteLine(long)]
G_M24659_IG07:  ;; offset=0x0053
       call     CORINFO_HELP_POLL_GC
       jmp      SHORT G_M24659_IG05

As you can see there is no allocation of Stopwatch at all.
@stephentoub Currently the JIT considers inlining Stopwatch.Stop as nonprofitable, maybe we can mark Stopwatch.Stop as aggressive inlining so that the whole Stopwatch can become a zero-cost abstraction?