Implement a self profiler #51657

wesleywiser · 2018-06-20T12:20:00Z

This is a work in progress implementation of #50780. I'd love feedback on the overall structure and code as well as some specific things:

The query categorization mechanism. This works but looks kind of ugly to me. Perhaps there's a better way?
The profiler assumes only one activity can run at a time. This is obviously incompatible with the ongoing parallel queries.
The output code is just a bunch of format!()s. Is there a better way to generate markdown or json in the compiler?
The query categorizations are likely wrong. I've marked what seemed obvious to me but I'm sure I got a lot of them wrong.

The overhead currently seems very low. Running perf on a sample compilation with profiling enabled reveals:

rust-highfive · 2018-06-20T12:20:04Z

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

rust-highfive · 2018-06-20T12:34:27Z

The job x86_64-gnu-llvm-3.9 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.


[00:04:59] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:59] tidy error: /checkout/src/librustc/ty/query/plumbing.rs:663: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:107: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:115: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:145: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:173: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:192: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:195: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:204: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:206: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:218: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:223: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:228: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:244: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:252: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:260: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:269: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:270: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:277: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:278: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:291: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:292: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:293: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:294: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:321: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:339: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:357: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:365: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:371: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:386: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:399: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/ty/query/mod.rs:457: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:96: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:112: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:113: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:129: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:212: trailing whitespace
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:214: trailing whitespace
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:226: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:243: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:248: line longer than 100 chars
[00:04:59] tidy error: /checkout/src/librustc/util/profiling.rs:264: line longer than 100 chars
[00:05:01] some tidy checks failed
[00:05:01] 
[00:05:01] 
[00:05:01] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:05:01] 
[00:05:01] 
[00:05:01] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:05:01] Build completed unsuccessfully in 0:01:51
[00:05:01] Build completed unsuccessfully in 0:01:51
[00:05:01] Makefile:79: recipe for target 'tidy' failed
[00:05:01] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:02e0b590
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:2336de62:start=1529497634384776948,finish=1529497634390273095,duration=5496147
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:13f31e20
$ head -30 ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
head: cannot open ‘./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers’ for reading: No such file or directory
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:00007842
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

Zoxc · 2018-06-20T13:48:07Z

src/librustc_driver/driver.rs

@@ -666,13 +675,15 @@ pub fn phase_1_parse_input<'a>(
        profile::begin(sess);
    }

+    sess.profiler(|p| p.start_activity(ProfileCategory::Parsing));


Could you make the time function take an Option<ProfileCategory> and have it do these calls instead where appropriate?

Yes, that would probably work. Good idea!

nikomatsakis · 2018-06-20T18:55:54Z

cc @rust-lang/compiler and specifically @eddyb

nikomatsakis · 2018-06-20T19:18:36Z

src/librustc/ty/query/mod.rs

@@ -97,228 +98,228 @@ pub use self::on_disk_cache::OnDiskCache;
 // as they will raise an fatal error on query cycles instead.
 define_queries! { <'tcx>
    /// Records the type of every item.
-    [] fn type_of: TypeOfItem(DefId) -> Ty<'tcx>,
+    [] category<Other> fn type_of: TypeOfItem(DefId) -> Ty<'tcx>,


This is interesting! I like the way you can label the categories so declaratively, but I don't love the syntax. I'd sort of like #[category(Other)] or something that looks more like Rust.

It could also go inside the [] -- this was always meant to "house" important flags and so forth. Are we even using that for anything anymore? Maybe we should remove it...

Yeah, the current syntax is not very good. My macro-foo is pretty weak so I just did this temporarily. I'd be happy to circle back and try to make it work in the [].

nikomatsakis · 2018-06-20T19:19:07Z

src/librustc/ty/query/mod.rs

+    [fatal_cycle] category<Codegen> fn is_sanitizer_runtime: IsSanitizerRuntime(CrateNum) -> bool,
+    [fatal_cycle] category<Codegen> fn is_profiler_runtime: IsProfilerRuntime(CrateNum) -> bool,
+    [fatal_cycle] category<Codegen> fn panic_strategy: GetPanicStrategy(CrateNum) -> PanicStrategy,
+    [fatal_cycle] category<Codegen> fn is_no_builtins: IsNoBuiltins(CrateNum) -> bool,


Answer: yes, we are still using [] for something. Maybe we should change that to #[fatal_cycle] as well.

I kind of like that idea, but it seems a little surprising to me that in this context #[whatever] doesn't mean what it normally would. For example, #[derive(Clone)] would result in some kind of weird macro expansion error.

I think this is what #[...] normally means. That is, #[..] is some kind of meta-data interpreted by the context. In this context, this is a macro, and macros often re-interpret #[foo] annotations. (Consider for example #[derive] which allows for annotations on fields etc that aren't normally used.) That doesn't mean that all attributes would be appropriate of course (e.g. #[derive(Clone)] doesn't make sense on a function anyhow)

Fair enough! I don't think I've seen a macro re-interpret #[] annotations before so it seemed strange to me. I can certainly do this though.

Interestingly enough, it looks like define_queries! already handles attributes. This doesn't appear to be used currently or in the recent history of this file. @nikomatsakis would you like me to continue with this idea and remove support for regular #[thing] attributes from the macro? What do you think of @eddyb's idea? I quite like it myself.

I'm fine with @eddyb's idea too

nikomatsakis · 2018-06-20T19:21:00Z

src/librustc_typeck/lib.rs

@@ -340,6 +341,8 @@ pub fn provide(providers: &mut Providers) {
 pub fn check_crate<'a, 'tcx>(tcx: TyCtxt<'a, 'tcx, 'tcx>)
                             -> Result<(), CompileIncomplete>
 {
+    tcx.sess.profiler(|p| p.start_activity(ProfileCategory::TypeChecking));


(is there a non-trivial amount of work here that takes place outside of queries?)

Hmm... I'm not sure off hand. I can investigate.

nikomatsakis · 2018-06-20T19:21:57Z

src/librustc_driver/driver.rs

@@ -351,6 +352,14 @@ pub fn compile_input(
        sess.print_perf_stats();
    }


one question I'm wondering: how do we find the "total compilation time" number? I'd like to see some "start activity" and "end activity" that takes place at a really high-up place, like main, that should truly account for everything

I believe this is just a matter of creating the SelfProfiler earlier in the process lifecycle. Right now it's created when Session::new() is called, but there's no real reason it couldn't be created earlier.

That's probably early enough -- when does it make its final measurement?

At the end of compile_input() right after we run the linker and output the other performance diagnostics.

nikomatsakis · 2018-06-20T19:23:34Z

@wesleywiser I left a few comments, but overall I'm pretty excited. I'd love to have simple-and-easy profiling, and this seems like a good start.

Hmm, another question I didn't satisfy for myself: how do we separate out the timing results from sub-queries from the parent query?

@Zoxc will have to weigh in on the best way to handle parallelization, but it seems like we ought to be able to sum up the timing results per-thread and them sum them up at the end across all threads.

wesleywiser · 2018-06-20T19:48:35Z

@nikomatsakis

Hmm, another question I didn't satisfy for myself: how do we separate out the timing results from sub-queries from the parent query?

Right now, when SelfProfiler::start_activity() is called, it checks to see if there's already an activity (query) being timed. If there is, we stop that timer, record its time so far, and push it onto a stack. We then start the new activity's timer. When SelfProfiler::end_activity() is called, we stop the current one, record its time, and then check to see if there is a timer on the stack. If there is, we start it up again.

petrochenkov · 2018-06-21T14:20:25Z

r? @Zoxc

eddyb · 2018-06-22T03:28:55Z

This is really neat! I've wanted this for a while now 🎉
My suggestion for categorization would be to just reorder the queries and have the macro take groups, e.g. Typeck { ... } Other { ... }. That is, if we believe it's significant enough.

eddyb · 2018-06-22T03:30:18Z

src/librustc/util/profiling.rs

+    BorrowChecking,
+    Codegen,
+    Linking,
+    Other,


My suggestion would make code like this auto-generatable so I prefer it even more.

@eddyb Latest commit makes this all auto-generated

nikomatsakis · 2018-06-25T20:53:52Z

My suggestion for categorization would be to just reorder the queries and have the macro take groups, e.g. Typeck { ... } Other { ... }. That is, if we believe it's significant enough.

Well, this sounded good to me at first, but now I'm wondering if people will wind up miscategorizing things because they'll just insert queries into some random category without being able to easily see if it's the right or wrong place. It sort of reminds me of public: etc from C++, which always seemed like a fine idea, but in practice I often found it hard to tell what the visibility of things were unless it was labeled on more-or-less every item.

bors · 2018-06-28T04:04:43Z

☔ The latest upstream changes (presumably #51538) made this pull request unmergeable. Please resolve the merge conflicts.

eddyb · 2018-06-28T14:37:22Z

@nikomatsakis Worst case we can move them later, seems like less of a problem than line noise.

pietroalbini · 2018-07-09T10:57:41Z

Ping from triage @wesleywiser! It's been a while since we heard from you, will you have time to work on this again?

wesleywiser · 2018-07-09T18:02:51Z

Yes! I've been working on this for a while now but I think I'm stuck on the macro changes suggested above. I'm going to continue trying to make progress but help from anybody in the community familiar with writing macros would be greatly appreciated!

mark-i-m · 2018-07-10T03:12:41Z

Not sure if this is the best way to do it, but the easiest thing I can think of would be to rename what you have to define_queries-inner. Then define a new define_queries that looks something like this:

macro_rules! define_queries {
  (Category1 { $(queries1:tt);* }
   Category2 { $(queries2:tt);* }
   ... ) => {
    define_queries_inner!(
      $(category<Category1> $queries1)*
      $(category<Category2> $queries2)*
      ...
    );
  }
}

wesleywiser · 2018-07-12T03:12:53Z

Thanks @mark-i-m, that's helpful! Unfortunately, I'm still not quite seeing the solution. I have this:

macro_rules! define_queries {
    $($category:ident {
        $(queries:tt),*
    }),* => {
        define_queries_inner!(
            $($(category<$category> $queries)), //issue
        )
    }
}

but when expanding the queries, the macro needs to look "up" to the enclosing category. I can't think of anyway to do that.

mark-i-m · 2018-07-12T04:11:20Z

Hmm... Slight modification:

macro_rules! define_queries {
    $($category:ident {
        $(queries:tt);* // note `;` instead of comma
    }),* => {
        define_queries_inner!(
            $($(category<$category> $queries);*)* // note the two `*`s and `;`
        )
    }
}

IIUC ; cannot occur in the middle of a query definition (can someone confirm this?). So using semicolon as a separator should unambiguously distinguish adjacent queries. If I'm right, this means that each query will be a different match for $queries and we will actually be adding category in front of each query.

Of course, you will need to modify define_queries_inner to accept category<$category> at the beginning rather than after the [] part...

Let me know if this didn't work.

wesleywiser · 2018-07-13T02:33:08Z

@mark-i-m Perfect! That's just what I needed. I ran into some issues trying to get the $(queries:tt);* part to work but comments you left were really helpful. This works FYI:

macro_rules! define_queries {
    (<$tcx:tt> $($category:ident {
        $($(#[$attr:meta])* [$($modifiers:tt)*] fn $name:ident: $node:ident($K:ty) -> $V:ty,)*
    },)*) => {
        define_queries_inner! { <$tcx>
            $($( $(#[$attr])* category<$category> [$($modifiers)*] fn $name: $node($K) -> $V,)*)*
        }
    }
}

macro_rules! define_queries_inner {
    (<$tcx:tt>
     $($(#[$attr:meta])*
        category<$category:ident> [$($modifiers:tt)*] fn $name:ident: $node:ident($K:ty) -> $V:ty,)*) => {
           ....
    }
}

Thank you!!

mark-i-m · 2018-07-13T02:34:07Z

Great! Glad I could help :)

Nice work!

wesleywiser · 2018-07-17T02:44:23Z

Rebased and updated with the snazzy new macro syntax

rust-highfive · 2018-07-17T02:54:08Z

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.


[00:04:10] travis_fold:start:tidy
travis_time:start:tidy
tidy check
[00:04:11] tidy error: /checkout/src/librustc/ty/query/plumbing.rs:652: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/ty/query/mod.rs:133: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/ty/query/mod.rs:277: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/ty/query/mod.rs:353: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:96: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:112: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:113: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:129: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:212: trailing whitespace
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:214: trailing whitespace
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:226: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:243: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:248: line longer than 100 chars
[00:04:11] tidy error: /checkout/src/librustc/util/profiling.rs:264: line longer than 100 chars
[00:04:12] some tidy checks failed
[00:04:12] 
[00:04:12] 
[00:04:12] command did not execute successfully: "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-tools-bin/tidy" "/checkout/src" "/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" "--no-vendor" "--quiet"
[00:04:12] 
[00:04:12] 
[00:04:12] failed to run: /checkout/obj/build/bootstrap/debug/bootstrap test src/tools/tidy
[00:04:12] Build completed unsuccessfully in 0:00:55
[00:04:12] Build completed unsuccessfully in 0:00:55
[00:04:12] Makefile:79: recipe for target 'tidy' failed
[00:04:12] make: *** [tidy] Error 1

The command "stamp sh -x -c "$RUN_SCRIPT"" exited with 2.
travis_time:start:1cc76eaf
$ date && (curl -fs --head https://google.com | grep ^Date: | sed 's/Date: //g' || true)
---
travis_time:end:1b0f422e:start=1531795613959748469,finish=1531795613966714832,duration=6966363
travis_fold:end:after_failure.3
travis_fold:start:after_failure.4
travis_time:start:0522ebe0
$ ln -s . checkout && for CORE in obj/cores/core.*; do EXE=$(echo $CORE | sed 's|obj/cores/core\.[0-9]*\.!checkout!\(.*\)|\1|;y|!|/|'); if [ -f "$EXE" ]; then printf travis_fold":start:crashlog\n\033[31;1m%s\033[0m\n" "$CORE"; gdb -q -c "$CORE" "$EXE" -iex 'set auto-load off' -iex 'dir src/' -iex 'set sysroot .' -ex bt -ex q; echo travis_fold":"end:crashlog; fi; done || true
travis_fold:end:after_failure.4
travis_fold:start:after_failure.5
travis_time:start:0d692a7a
travis_time:start:0d692a7a
$ cat ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers || true
cat: ./obj/build/x86_64-unknown-linux-gnu/native/asan/build/lib/asan/clang_rt.asan-dynamic-i386.vers: No such file or directory
travis_fold:end:after_failure.5
travis_fold:start:after_failure.6
travis_time:start:00fb8440
$ dmesg | grep -i kill

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

pietroalbini · 2018-07-30T17:20:23Z

Ping from triage @Zoxc! This PR needs your review.

michaelwoerister · 2018-07-31T08:26:45Z

I haven't seen @Zoxc around in a while. Assigning to @nikomatsakis, who worked with @wesleywiser on this PR already. If you are too busy, @nikomatsakis, I can take a look too.

eddyb · 2018-08-02T19:25:00Z

@Zoxc Do you object to merging this PR? I think I want to r+ it.
@wesleywiser Can you rebase?

wesleywiser · 2018-08-02T22:59:52Z

@eddyb Rebased

eddyb · 2018-08-02T23:58:54Z

@bors r+ Thanks!

bors · 2018-08-02T23:58:55Z

📌 Commit 2d3a0a9 has been approved by eddyb

bors · 2018-08-03T00:50:17Z

⌛ Testing commit 2d3a0a9 with merge 1e3c45a...

Implement a self profiler This is a work in progress implementation of #50780. I'd love feedback on the overall structure and code as well as some specific things: - [The query categorization mechanism](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). This works but looks kind of ugly to me. Perhaps there's a better way? - [The profiler assumes only one activity can run at a time](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R177). This is obviously incompatible with the ongoing parallel queries. - [The output code is just a bunch of `format!()`s](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-f8a403b2d88d873e4b27c097c614a236R91). Is there a better way to generate markdown or json in the compiler? - [The query categorizations are likely wrong](https://github.com/rust-lang/rust/compare/master...wesleywiser:wip_profiling?expand=1#diff-19e0a69c10eff31eb2d16805e79f3437R101). I've marked what seemed obvious to me but I'm sure I got a lot of them wrong. The overhead currently seems very low. Running `perf` on a sample compilation with profiling enabled reveals: ![image](https://user-images.githubusercontent.com/831192/41657821-9775efec-7462-11e8-9e5e-47ec94105d9d.png)

bors · 2018-08-03T02:53:12Z

☀️ Test successful - status-appveyor, status-travis
Approved by: eddyb
Pushing 1e3c45a to master...

rust-highfive assigned petrochenkov Jun 20, 2018

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jun 20, 2018

Zoxc reviewed Jun 20, 2018

View reviewed changes

nikomatsakis reviewed Jun 20, 2018

View reviewed changes

rust-highfive assigned Zoxc and unassigned petrochenkov Jun 21, 2018

eddyb reviewed Jun 22, 2018

View reviewed changes

TimNN added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jul 3, 2018

wesleywiser force-pushed the wip_profiling branch 2 times, most recently from f937779 to b8198ac Compare July 17, 2018 02:40

michaelwoerister assigned nikomatsakis and unassigned Zoxc Jul 31, 2018

wesleywiser added 14 commits August 2, 2018 18:57

Basic profiling

45482c6

Basic incremental stats

177776d

Add units to times

aceee88

Switch to markdown output

0f43800

Fix some missed query data

6a0d37b

Remove redundant s in output

d3aa593

Fix more missed query data

e50dfe6

First pass at json output

51cc594

Refactor json printing

4552607

Include query hits/totals

579faca

Include additional data in the json output

256a6e4

Remove some dead code

97ab37e

Fix tidy

60c2e9a

Generate self-profiler types with macros

2d3a0a9

wesleywiser force-pushed the wip_profiling branch from 7e3f300 to 2d3a0a9 Compare August 2, 2018 22:59

wesleywiser changed the title ~~[WIP] Self Profiler~~ Implement a self profiler Aug 2, 2018

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-review Status: Awaiting review from the assignee but also interested parties. labels Aug 2, 2018

bors merged commit 2d3a0a9 into rust-lang:master Aug 3, 2018

		@@ -351,6 +352,14 @@ pub fn compile_input(
		sess.print_perf_stats();
		}

Implement a self profiler #51657

Implement a self profiler #51657

Conversation

wesleywiser commented Jun 20, 2018

rust-highfive commented Jun 20, 2018

rust-highfive commented Jun 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Jun 20, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

wesleywiser Jun 20, 2018 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Jun 20, 2018

wesleywiser commented Jun 20, 2018

petrochenkov commented Jun 21, 2018

eddyb commented Jun 22, 2018

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nikomatsakis commented Jun 25, 2018

bors commented Jun 28, 2018

eddyb commented Jun 28, 2018 • edited Loading

pietroalbini commented Jul 9, 2018

wesleywiser commented Jul 9, 2018

mark-i-m commented Jul 10, 2018

wesleywiser commented Jul 12, 2018

mark-i-m commented Jul 12, 2018

wesleywiser commented Jul 13, 2018

mark-i-m commented Jul 13, 2018

wesleywiser commented Jul 17, 2018

rust-highfive commented Jul 17, 2018

pietroalbini commented Jul 30, 2018

michaelwoerister commented Jul 31, 2018

eddyb commented Aug 2, 2018

wesleywiser commented Aug 2, 2018

eddyb commented Aug 2, 2018

bors commented Aug 2, 2018

bors commented Aug 3, 2018

bors commented Aug 3, 2018

wesleywiser Jun 20, 2018 •

edited

Loading

eddyb commented Jun 28, 2018 •

edited

Loading