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

Investigate measureme intergration #1782

Closed
Aaron1011 opened this issue Apr 26, 2021 · 7 comments
Closed

Investigate measureme intergration #1782

Aaron1011 opened this issue Apr 26, 2021 · 7 comments
Labels
A-interpreter Area: affects the core interpreter C-proposal Category: a proposal for something we might want to do, or maybe not; details still being worked out

Comments

@Aaron1011
Copy link
Member

Aaron1011 commented Apr 26, 2021

The rust compiler uses measureme to profile query execution times. I think it would be relatively straightforward to integrate this into Miri to allow profiling the underlying program being executed. For example, we could generate a measureme 'event' when we start executing a MIR body, allowing us to generate a 'callstack' of functions that consume a large amount of execution time under Miri. This could be useful in tracking down issues like #1780, where Miri is spending a large amount of time executing some particular part of the program.

Integrating this with Miri's virtual threads could be tricky, so we could limit this to the single-threaded case at first.

@RalfJung RalfJung added the C-proposal Category: a proposal for something we might want to do, or maybe not; details still being worked out label Apr 27, 2021
@RalfJung
Copy link
Member

Does measureme have support for "multiple independent stacks"? This sounds like something that would also come up e.g. with concurrent execution of queries.

@bjorn3
Copy link
Member

bjorn3 commented Apr 27, 2021

Measureme supports multiple threads. It doesn't natively support indicating that a thread is currently not scheduled, but you could add an event for that beginning when the thread stops running and stopping once it gets scheduled again.

@Aaron1011
Copy link
Member Author

Aaron1011 commented Jun 8, 2021

This was implemented in #1791. We still night want to investigate some form of sampling, to prevent the generated profiler output from becoming enormous on long runs.

@RalfJung
Copy link
Member

RalfJung commented Jun 8, 2021

What's a "splint"?

@Aaron1011
Copy link
Member Author

That was supposed to say 'sampling' - I have no idea how autocorrect ended up with 'splint' :laug

@RalfJung
Copy link
Member

RalfJung commented Jun 8, 2021

Okay. So do you want to keep the issue open for that? The issue title and description don't match, so a new issue might be better. Or we could update those.

@RalfJung
Copy link
Member

RalfJung commented Mar 5, 2022

Closing this for now as "fixed by #1791", if you think more could be done here please open a new issue that describes the details. :)

@RalfJung RalfJung closed this as completed Mar 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-interpreter Area: affects the core interpreter C-proposal Category: a proposal for something we might want to do, or maybe not; details still being worked out
Projects
None yet
Development

No branches or pull requests

3 participants