Fix user and kernel times on Windows

[clemenswasser]

Description

By using a job object and attaching it to the spawned process before launch, we can record the total user and kernel times of it and all of its child processes. Sadly extracting the raw handle of the main_thread_handle is still nightly only 😢 (see: rust-lang/rust#96723) and required, in order to resume a initially suspended process. Therefore this new CPUTimer implementation is guarded behind a new nightly cargo feature and not enabled by default.

Example

Before:

> cargo run --quiet -- 'cargo fmt'
Benchmark 1: cargo fmt
  Time (mean ± σ):     175.6 ms ±   1.1 ms    [User: 0.9 ms, System: 8.4 ms]
  Range (min … max):   173.3 ms … 177.3 ms    16 runs

After:

> cargo run --quiet -- 'cargo fmt'
Benchmark 1: cargo fmt
  Time (mean ± σ):     175.8 ms ±   1.9 ms    [User: 91.5 ms, System: 62.5 ms]
  Range (min … max):   173.5 ms … 180.7 ms    16 runs

Fixes: #368

[sharkdp]

Thank you very much for your contribution and for the clear implementation & documentation!

Sadly extracting the raw handle of the main_thread_handle is still nightly only cry (see: rust-lang/rust#96723) and required, in order to resume a initially suspended process.

Just to make sure: the linked ticket says "Finding that thread from the process handle can be a bit convoluted", which sounds like it is actually possible to retrieve the handle without that nightly-only feature (potentially using some low-level winapi code). I would appreciate if we could quickly look into that. It would be fantastic if we could make this work on stable Rust.

Therefore this new CPUTimer implementation is guarded behind a new nightly cargo feature and not enabled by default.

Thank you. I think I understand the intention behind the feature gate. On the other hand, it's not like the current CPUTimer implementation is really a reasonable alternative that someone would like to choose. It's just broken.

In this sense, I think it would be great if the absence of the new feature gate would completely disable the user/kernel time feature on Windows. What do you think?

Minor point: calling this feature nightly is a bit confusing IMO. How about using a more descriptive name (e.g. windows_user_and_system_times).

[clemenswasser]

@sharkdp thanks for your comments. I'll look into them tomorrow. I already found a undocumented ntdll function NtResumeProcess, which resumes a process by HANDLE, which we could potentially use and before that I played around with a implementation using CreateToolhelp32Snapshot for finding the main thread, but using NtResumeProcess should definitely be better in terms of performance and code size 😁.

[clemenswasser]

With the latest commit it works on stable using the undocumented but well known ntdll.dll!NtResumeProcess which exists since Windows XP. When using nightly the feature windows_process_extensions_main_thread_handle can be set to use the unstable feature with the same name. The dependency on once_init is not a problem, since clap was already using it anyway.
Also I don't know why the ActiveProcesses == 0 assertion triggered on https://github.com/sharkdp/hyperfine/runs/7864408316...
For me locally this never triggered for simple test cases like cargo run -- 'cargo fmt'

[clemenswasser]

@sharkdp ping. Can I do something to help merge this?

[sharkdp]

No - this is great! Thank you very much.