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

Use measureme in self profiler #59515

Merged
merged 1 commit into from
Apr 13, 2019
Merged

Use measureme in self profiler #59515

merged 1 commit into from
Apr 13, 2019

Conversation

wesleywiser
Copy link
Member

@wesleywiser wesleywiser commented Mar 29, 2019

r? @michaelwoerister

Changes are still very rough.

I'm not sure what the right way to add the measureme dependency is. Currently it's just added with a relative path which Works On My Machine ™️.

I'm also not sure what to do with the category data.

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 29, 2019
@michaelwoerister
Copy link
Member

Looks like a good start! Eventually I'd like to have query names instead of dep-node names here but I don't know how to exactly do that yet.

Have you done performance tests on Windows? If the mmap-sink performance worse than the file-sink there, I think I'd like to get rid of the memmap dependency and implement the mmap-sink only on Unix via direct libc calls (we'll need some stuff from libc that memmap doesn't support anyway). On Windows we'd just use the file-sink.

For now, I think we should just ignore the category data. Later we could encode it in the event_id if we wanted to.

I think we can just publish measureme on crates.io and have lots of major version changes. The other option would be a git dependency. But that's something we should discuss with wg-meta.

@wesleywiser
Copy link
Member Author

Looks like a good start! Eventually I'd like to have query names instead of dep-node names here but I don't know how to exactly do that yet.

Originally I passed Query<'tcx>s into the profiler methods but I couldn't figure out how to preregister the query names so I had to use a FxHashSet to keep track of which query names had been interned into the string table and which hadn't. Maybe the overhead of that could be reduced more but removing it in favor of using dep-node names and pre-registering the names made a noticeable difference in performance.

Have you done performance tests on Windows?

I've been working on getting rustc to build on my Windows box. It's been a long time since I used it and my msvc toolchain was completely out of date. I think that's resolved now and I'm just waiting for LLVM to build. I should have the performance data tonight.

For now, I think we should just ignore the category data.

Ok that's fine. I'll remove the other unused _category parameters as well.

I think we can just publish measureme on crates.io and have lots of major version changes. The other option would be a git dependency. But that's something we should discuss with wg-meta.

I'd personally vote for publishing on crates.io

@wesleywiser
Copy link
Member Author

Results of testing on Windows:

Test Case Time Taken
regex rustc 5.02s
regex rustc + -Z self-profile FileSerializationSink 5.92s
regex rustc + -Z self-profile MmapSerializationSink 6.04s

@michaelwoerister
Copy link
Member

Great, thanks for getting those numbers. Let's use the FileSerializationSink on Windows then.

@michaelwoerister
Copy link
Member

Eventually I'd like to have query names instead of dep-node names here but I don't know how to exactly do that yet.

It looks like a recent PR fixed this for us by making DepKind variants and query names match up :)

@wesleywiser
Copy link
Member Author

Oh, wonderful! I can make that change tonight. Do we have consensus on how to add the measureme dependency? I think that's the last thing that needs a fixup before this can be merged.

@michaelwoerister
Copy link
Member

Let's go via crates.io, I'd say.

@michaelwoerister
Copy link
Member

Note that Q::to_dep_node() is potentially expensive and in non-incremental builds it's not called at all, so we'll have to cache the query name StringId afterall. Ideally it would be created at the same time as the query caches and stored in a field somewhere.

@wesleywiser
Copy link
Member Author

@michaelwoerister Do you like the approach in edff02e better?

@michaelwoerister
Copy link
Member

I do -- but it still has some runtime overhead for cloning the query key. Could you try to add an associated constant to QueryConfig that holds the right QueryName variant? Then we could pass the QueryName directly to the record methods. You could maybe even replace the current NAME constant (not sure if it's used anywhere else).

@wesleywiser
Copy link
Member Author

Oh yeah, that's a better idea

@michaelwoerister
Copy link
Member

I left a few comments. Looks like this is almost ready to merge.

@wesleywiser
Copy link
Member Author

Thanks for the feedback @michaelwoerister! I've made those changes, pushed, and marked this PR as ready for review.

@wesleywiser
Copy link
Member Author

@bors r=michaelwoerister

@bors
Copy link
Contributor

bors commented Apr 13, 2019

📌 Commit 56e434d has been approved by michaelwoerister

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 13, 2019
bors added a commit that referenced this pull request Apr 13, 2019
[WIP] Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from #59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
@bors
Copy link
Contributor

bors commented Apr 13, 2019

⌛ Testing commit 56e434d with merge 896c3a5...

bors added a commit that referenced this pull request Apr 13, 2019
Use measureme in self profiler

r? @michaelwoerister

~Changes are still very rough.~

~I'm not sure what the right way to add the `measureme` dependency is. Currently it's just added with a relative path which Works On My Machine ™️.~

I'm also not sure what to do with the category data.
@bors
Copy link
Contributor

bors commented Apr 13, 2019

☀️ Test successful - checks-travis, status-appveyor
Approved by: michaelwoerister
Pushing 896c3a5 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Apr 13, 2019
@bors bors merged commit 56e434d into rust-lang:master Apr 13, 2019
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 18, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 19, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 19, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Centril added a commit to Centril/rust that referenced this pull request Apr 19, 2019
…, r=wesleywiser

Implement event filtering for self-profiler.

This is a first sketch for event filtering in the self-profiler, something that we'll want in order to keep profiling overhead low in the common case. The PR contains the commits from rust-lang#59515 and, for the moment, is meant for performance testing.

r? @wesleywiser
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
merged-by-bors This PR was explicitly merged by bors. S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants