`Measure-Command` reports incorrect results
See original GitHub issuePrerequisites
- Write a descriptive title.
- Make sure you are able to repro it on the latest released version
- Search the existing issues.
- Refer to the FAQ.
- Refer to Differences between Windows PowerShell 5.1 and PowerShell.
Steps to reproduce
I have a little .NET app (targeting .NET 6/7), and I want to measure how long it takes to launch it. The app automatically closes itself upon launch and reports the elapsed time. The time reported by Measure-Command
cmdlet and inconsistent with the time reported by the app.
When I ran the cmdlet I get these results from the cmdlet:
PS throwaway\winforms-nativeaot> Measure-Command { .\bin\Release\net6.0-windows\winforms-nativeaot.exe }
Days : 0
Hours : 0
Minutes : 0
Seconds : 0
Milliseconds : 88
Ticks : 881686
TotalDays : 1.02046990740741E-06
TotalHours : 2.44912777777778E-05
TotalMinutes : 0.00146947666666667
TotalSeconds : 0.0881686
TotalMilliseconds : 88.1686
DebugViewer report the data from the app:
[28008] winforms_nativeaot: time taken: 146.5512 ms || 1465512 ticks // 146 ms
When I ran a comparable command from bash, I get these results:
$ time ./bin/Release/net6.0-windows/winforms-nativeaot.exe
real 0m0.266s
user 0m0.000s
sys 0m0.000s
And I also tried the good ol’ cmd:
D:\Development\throwaway\winforms-nativeaot>cmd /v:on /c "echo !TIME! & .\bin\Release\net6.0-windows\winforms-nativeaot.exe & echo !TIME!"
14:33:16.35
14:33:16.59
App | PowerShell 5.1 | PowerShell 7.2 | Bash | Cmd |
---|---|---|---|---|
146 ms | 34.337 | 88.1686 | 266 | 240 |
It’s clear that PowerShell reports grossly incorrect results as it can’t take less time than the actual app. Bash reports the correct time as there’s some overhead to launch the app before it gets to the Main
entrypoint.
To verify, I have also run this, and results are surprising to say the least:
Measure-Command { timeout 3 }
Days : 0
Hours : 0
Minutes : 0
Seconds : 2
Milliseconds : 322
Ticks : 23221427
TotalDays : 2.68766516203704E-05
TotalHours : 0.000645039638888889
TotalMinutes : 0.0387023783333333
TotalSeconds : 2.3221427
TotalMilliseconds : 2322.1427
.NET app code
using System.Diagnostics;
namespace winforms_nativeaot;
static class Program
{
[STAThread]
static void Main()
{
Stopwatch stopwatch = Stopwatch.StartNew();
// To customize application configuration such as set high DPI settings or default font,
// see https://aka.ms/applicationconfiguration.
ApplicationConfiguration.Initialize();
Application.ApplicationExit += (s, e) =>
{
stopwatch.Stop();
Trace.WriteLine($"winforms_nativeaot: time taken: {stopwatch.Elapsed.TotalMilliseconds} ms || {stopwatch.ElapsedTicks} ticks // {stopwatch.ElapsedMilliseconds} ms");
};
Application.Run(new Form1());
}
}
public partial class Form1 : Form
{
public Form1()
{
this.Activated += (_, __) => Application.Exit();
}
}
Expected behavior
The reported time is correct, at least within the same order of magnitude.
Actual behavior
The reported time is grossly inaccurate.
Error details
No response
Environment data
Name Value
---- -----
PSVersion 5.1.22621.608
PSEdition Desktop
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
BuildVersion 10.0.22621.608
CLRVersion 4.0.30319.42000
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
----
Name Value
---- -----
PSVersion 7.2.7
PSEdition Core
GitCommitId 7.2.7
OS Microsoft Windows 10.0.22621
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Visuals
No response
Issue Analytics
- State:
- Created a year ago
- Comments:5
Measure-Command {notepad.exe}
Will start notepad, and return to the PowerShell prompt. The time reported is the time to return from launching notepad, - the command doesn’t wait for notepad to terminateto do that you need to use
Measure-Command {start -wait notepad.exe}
(h)[-1].Duration
Works alone (h is an alias for get history)
The time in cmd will be the time to return to the prompt - again try it with notepad - you’ll get a time before the app has closed. It’s likely there is some overhead starting the process and I suspect start process polls to see if the process ID is still running so it won’t give super accurate times.
Should be more accurate.