Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sys.time returns wall-clock elapsed time on Windows not CPU time #7469

Closed
vicuna opened this issue Jan 27, 2017 · 3 comments · Fixed by #10408
Closed

Sys.time returns wall-clock elapsed time on Windows not CPU time #7469

vicuna opened this issue Jan 27, 2017 · 3 comments · Fixed by #10408

Comments

@vicuna
Copy link

vicuna commented Jan 27, 2017

Original bug ID: 7469
Reporter: @dra27
Assigned to: @dra27
Status: assigned (set by @dra27 on 2017-01-27T17:48:39Z)
Resolution: open
Priority: normal
Severity: minor
Version: 4.05.0 +dev/beta1/beta2/beta3/rc1
Target version: later
Category: runtime system and C interface

Bug description

The clock function in the Microsoft CRT returns wall clock and not CPU time.

Steps to reproduce

See https://msdn.microsoft.com/en-us/library/4e2ess30.aspx

Additional information

GetProcessTimes should give a value closer to getrusage(RUSAGE_SELF, ...)

@vicuna
Copy link
Author

vicuna commented Jan 27, 2017

Comment author: @dra27

Note that Unix.times does this correctly already.

@github-actions
Copy link

github-actions bot commented May 9, 2020

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 9, 2020
@dra27 dra27 removed the Stale label May 9, 2020
@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants