Skip to content

Conversation

@0xfk0
Copy link
Contributor

@0xfk0 0xfk0 commented Mar 5, 2020

This change adds StopProfile function to System.Runtime.ProfileOptimization
class and MulticoreJit feature of CoreCLR itself.

ProfileOptimization class always have SetProfileRoot and StartProfile
methods, but previously had no possibility to forcibly stop recording of
program profile and write out collected profile to the file.

Previously profiling can be stopped only at the time the program
finishes or after timeout expiration (timeout can be set by environment
variable COMPlus_MultiCoreJitProfileWriteDelay). Unfortunately timeout
works only on Windows platform, but not on Unix (no code for this
function in MulticoreJit component).

If we want speed up program startup time (if we are talking about
GUI applications -- this is the time util program's window appears on
the screen), we don't need to collect complete profile, until
termination of the program. We interested only on functions (methods),
which program runs at startup time. So we want to stop collecting
profile after program is "started" from users point of view.
This change adds this possibility.

There are several reasons, why we want to stop collecting profile
at some moment of time:

  • program might be buggy and always crashes on exit, for example,
    due to this reason profile might never be saved (or, program
    never terminates: it once started and works until reboot or
    power fail);

  • for large programs, profile might be too big: class loading
    and compilation of excessive set of the functions (which not
    required at program startup, but might be required only after
    some program function is activated) might slow down start up
    process.

This change adds StopProfile function to System.Runtime.ProfileOptimization
class and MulticoreJit feature of CoreCLR itself.

ProfileOptimization class always have SetProfileRoot and StartProfile
methods, but previously had no possibility to forcibly stop recording of
program profile and write out collected profile to the file.

Previously profiling can be stopped only at the time the program
finishes or after timeout expiration (timeout can be set by environment
variable COMPlus_MultiCoreJitProfileWriteDelay). Unfortunately timeout
works only on Windows platform, but not on Unix (no code for this
function in MulticoreJit component).

If we want speed up program startup time (if we are talking about
GUI applications -- this is the time util program's window appears on
the screen), we don't need to collect complete profile, until
termination of the program. We interested only on functions (methods),
which program runs at startup time. So we want to stop collecting
profile after program is "started" from users point of view.
This change adds this possibility.

There are several reasons, why we want to stop collecting profile
at some moment of time:

  * program might be buggy and always crashes on exit, for example,
    due to this reason profile might never be saved (or, program
    never terminates: it once started and works until reboot or
    power fail);

  * for large programs, profile might be too big: class loading
    and compilation of excessive set of the functions (which not
    required at program startup, but might be required only after
    some program function is activated) might slow down start up
    process.
@Dotnet-GitSync-Bot
Copy link
Collaborator

Note regarding the new-api-needs-documentation label:

This serves as a reminder for when your PR is modifying a ref *.cs file and adding/modifying public APIs, to please make sure the API implementation in the src *.cs file is documented with triple slash comments, so the PR reviewers can sign off that change.

@0xfk0
Copy link
Contributor Author

0xfk0 commented Mar 5, 2020

@jkotas
Copy link
Member

jkotas commented Mar 5, 2020

Unfortunately timeout works only on Windows platform, but not on Unix (no code for this
function in MulticoreJit component).

So would it be better to fix the timeout for Unix?

In any case, this is a new API that needs to go through https://github.com/dotnet/runtime/blob/master/docs/project/api-review-process.md

I am going to close this PR. We are not keeping open PRs for APIs that have not been approved. Thanks for understanding.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants