Stream: t-compiler/wg-self-profile

Topic: meeting 2019-09-19


pnkfelix (Sep 17 2019 at 11:16, on Zulip):

(placeholder for upcoming meeting)

mw (Sep 19 2019 at 09:58, on Zulip):

I took some notes for what the meeting could be about: https://hackmd.io/@michaelwoerister/Sy7D3pxPH/edit

mw (Sep 19 2019 at 09:59, on Zulip):

contains a suggested agenda

mw (Sep 19 2019 at 09:59, on Zulip):

I'll go have lunch now :)

simulacrum (Sep 19 2019 at 10:31, on Zulip):

:wave:

Wesley Wiser (Sep 19 2019 at 10:31, on Zulip):

:wave:

mw (Sep 19 2019 at 10:34, on Zulip):

:wave:

mw (Sep 19 2019 at 10:34, on Zulip):

I think @pnkfelix wanted to attend too

pnkfelix (Sep 19 2019 at 10:35, on Zulip):

i'm here now

mw (Sep 19 2019 at 10:36, on Zulip):

alright

mw (Sep 19 2019 at 10:36, on Zulip):

let's start then

mw (Sep 19 2019 at 10:36, on Zulip):

so my proposed agenda would be:

mw (Sep 19 2019 at 10:37, on Zulip):

1. establish the current status

mw (Sep 19 2019 at 10:37, on Zulip):

2. find out what we want to focus on next

mw (Sep 19 2019 at 10:37, on Zulip):

3. come up with action items

mw (Sep 19 2019 at 10:38, on Zulip):

shall we do that? did I forget something important?

Wesley Wiser (Sep 19 2019 at 10:38, on Zulip):

Sounds good to me

mw (Sep 19 2019 at 10:38, on Zulip):

ok

mw (Sep 19 2019 at 10:38, on Zulip):

so, the big project is still the "MVP"

mw (Sep 19 2019 at 10:38, on Zulip):

https://github.com/rust-lang/rust/issues/58967

mw (Sep 19 2019 at 10:39, on Zulip):

i.e. getting self-profiling onto perf.rlo

mw (Sep 19 2019 at 10:39, on Zulip):

we lost a bit of steam over the summer :)

Wesley Wiser (Sep 19 2019 at 10:39, on Zulip):

Yeah :)

mw (Sep 19 2019 at 10:40, on Zulip):

which is fine

mw (Sep 19 2019 at 10:40, on Zulip):

it's pretty far along actually

simulacrum (Sep 19 2019 at 10:40, on Zulip):

Indeed, yes -- I got the impression when I last looked at this (I think a few months ago) that we are pretty much ready to go ahead and add support to perf.rlo, just that we haven't quite gotten around to it mostly

mw (Sep 19 2019 at 10:40, on Zulip):

yup

mw (Sep 19 2019 at 10:40, on Zulip):

did we properly specify what it should look like on perf.rlo

mw (Sep 19 2019 at 10:41, on Zulip):

I know we chatted about it

simulacrum (Sep 19 2019 at 10:41, on Zulip):

I think no -- I recall lots of discussion -- but I think we also decided that an initial bit could be to just get the output of measureme summarize or so on the page (via links or something)

mw (Sep 19 2019 at 10:41, on Zulip):

the todo list in the tracking issue is still up-to-date, I think

mw (Sep 19 2019 at 10:42, on Zulip):

I remember that one should be able to "zoom into" a specific benchmark

mw (Sep 19 2019 at 10:42, on Zulip):

and have a comparison of time spent in each query

pnkfelix (Sep 19 2019 at 10:43, on Zulip):

This may or may not be related: I would like the freedom to add new measurements that capture data at a finer grain, but @mw was worried about that perturbing the UX for people just trying to see the overall picture (presumably via measureme summarize).

mw (Sep 19 2019 at 10:43, on Zulip):

i.e. you click on a comparison in the comparison view and get to a new page comparing each query

simulacrum (Sep 19 2019 at 10:43, on Zulip):

hm, yes, I do recall something to this effect

pnkfelix (Sep 19 2019 at 10:43, on Zulip):

So we may want to say up front what events will be filtered out from the perf.rlo presentation?

mw (Sep 19 2019 at 10:44, on Zulip):

yes, filtering is already implemented and perf.rlo would only do stuff that doesn't add much overhead

Wesley Wiser (Sep 19 2019 at 10:44, on Zulip):

(We talked about the details view around here https://rust-lang.zulipchat.com/#narrow/stream/187831-t-compiler.2Fwg-self-profile/topic/meeting.202019-05-08/near/165155575 I think)

simulacrum (Sep 19 2019 at 10:44, on Zulip):

ah, well, I think @pnkfelix is talking about visual filtering, not collection wise

pnkfelix (Sep 19 2019 at 10:44, on Zulip):

I suppose both topics are relevant

mw (Sep 19 2019 at 10:45, on Zulip):

I think perf.rlo would basically give you what summarize does at the moment

pnkfelix (Sep 19 2019 at 10:45, on Zulip):

but basically, I want to know what the process is for me to add new instrumentation for my own use that won't perturb what perf.rlo shows

mw (Sep 19 2019 at 10:45, on Zulip):

plus comparison between two runs

simulacrum (Sep 19 2019 at 10:45, on Zulip):

I am not too concerned with collection overhead, bors is so slow these days that we can keep up no problem (especially with one of the servo crates broken...)

pnkfelix (Sep 19 2019 at 10:45, on Zulip):

it sounds like the answer is "don't change summarize"

simulacrum (Sep 19 2019 at 10:45, on Zulip):

I suspect that we'll probably want a summarize-perf or equivalent at some point soonish, too, for that reason

mw (Sep 19 2019 at 10:45, on Zulip):

perf.rlo has to deal with event types being added and removed anyway, right?

mw (Sep 19 2019 at 10:46, on Zulip):

because new queries get added

mw (Sep 19 2019 at 10:46, on Zulip):

or removed or renamed

simulacrum (Sep 19 2019 at 10:46, on Zulip):

Not today, but yes, in general it does

Wesley Wiser (Sep 19 2019 at 10:47, on Zulip):

So, I did land summarize diff over the summer which can handle new/missing events between runs https://github.com/rust-lang/measureme/tree/master/summarize#the-diff-sub-command

simulacrum (Sep 19 2019 at 10:47, on Zulip):

diff likely won't work well for us as we don't want to keep the raw event files around I presume? Though we could plausibly upload them to S3 if they're not too big

simulacrum (Sep 19 2019 at 10:47, on Zulip):

(I recall some size estimates earlier)

mw (Sep 19 2019 at 10:48, on Zulip):

yeah, we only want the post-processed artifacts, I think

Wesley Wiser (Sep 19 2019 at 10:48, on Zulip):

The diff actually can work with the processed json files as well as the raw events files.

mw (Sep 19 2019 at 10:48, on Zulip):

that would be a lot of data otherwise

simulacrum (Sep 19 2019 at 10:48, on Zulip):

ah, cool, okay -- so maybe we start by getting those processed json files stored as a first step

simulacrum (Sep 19 2019 at 10:49, on Zulip):

then we can figure out the rest once we have the raw data

simulacrum (Sep 19 2019 at 10:49, on Zulip):

presuming the processed json is "sufficient" for ~all uses?

mw (Sep 19 2019 at 10:50, on Zulip):

I think it is for the MVP

simulacrum (Sep 19 2019 at 10:50, on Zulip):

anyway, I can likely invest time into this

Wesley Wiser (Sep 19 2019 at 10:50, on Zulip):

I think it's sufficient for anything we'd want to expose from perf.rlo at this time

simulacrum (Sep 19 2019 at 10:50, on Zulip):

(likely with support from @Wesley Wiser if I have questions about self-profile filtering and such)

mw (Sep 19 2019 at 10:50, on Zulip):

cool

Wesley Wiser (Sep 19 2019 at 10:50, on Zulip):

I'd be glad to help out!

mw (Sep 19 2019 at 10:51, on Zulip):

so, I like roughly the table that summarize diff produces as a web page

mw (Sep 19 2019 at 10:51, on Zulip):

with the ability to sort by the different columns

mw (Sep 19 2019 at 10:52, on Zulip):

I think that would be pretty useful

simulacrum (Sep 19 2019 at 10:52, on Zulip):

indeed, yes -- that seems like a pretty good target for MVP (wouldn't be surprised if hardest bit is the sorting :)

mw (Sep 19 2019 at 10:53, on Zulip):

yeah :)

mw (Sep 19 2019 at 10:53, on Zulip):

the second part of the MVP is reviewing if we are recording the right events

mw (Sep 19 2019 at 10:53, on Zulip):

we already have queries and some LLVM and front-end stuff

mw (Sep 19 2019 at 10:54, on Zulip):

but trait selection would be interesting too, I think

mw (Sep 19 2019 at 10:54, on Zulip):

I can do a review of the kinds of data we are recording

Wesley Wiser (Sep 19 2019 at 10:54, on Zulip):

I know we're not currently recording anything for trait selection beyond what's captured by the general query infrastructure.

mw (Sep 19 2019 at 10:54, on Zulip):

and make a PR, and maybe in the process, come up with guidelines for when someone wants to add their own stuff

simulacrum (Sep 19 2019 at 10:54, on Zulip):

I think one concern from my end is that getting sort of into trait selection etc might be a bit prone to tracking a moving target? I don't really have a good sense of how quickly we expect polonius (so, regionck changes), chalk, etc. to start coming in

simulacrum (Sep 19 2019 at 10:55, on Zulip):

But generally speaking the review and PR sounds good!

mw (Sep 19 2019 at 10:55, on Zulip):

hm, I guess chalk is still some way off

mw (Sep 19 2019 at 10:55, on Zulip):

and we have to expect changes anyway

simulacrum (Sep 19 2019 at 10:56, on Zulip):

True, yes, I was just not sure if "some way" was weeks or months

mw (Sep 19 2019 at 10:56, on Zulip):

from the outside it would mostly look like a query got removed or added

pnkfelix (Sep 19 2019 at 10:56, on Zulip):

/me thinks time until chalk is the basis of implementation is measured in months

pnkfelix (Sep 19 2019 at 10:56, on Zulip):

@nikomatsakis ^ ?

simulacrum (Sep 19 2019 at 10:56, on Zulip):

If months then yeah, I think makes sense to invest

Wesley Wiser (Sep 19 2019 at 10:57, on Zulip):

We also don't really have a strategy for allowing dependent crates to use measureme

mw (Sep 19 2019 at 10:57, on Zulip):

it's not much of an investment and it's no big deal if it goes away again soon, I'd say

mw (Sep 19 2019 at 10:57, on Zulip):

can you elaborate, @Wesley Wiser ?

Wesley Wiser (Sep 19 2019 at 10:57, on Zulip):

eg. polonius might like to use measureme and have their instrumentations included in the overall self-profile results.

mw (Sep 19 2019 at 10:57, on Zulip):

that's true

mw (Sep 19 2019 at 10:57, on Zulip):

I never thought about that, actually

Wesley Wiser (Sep 19 2019 at 10:58, on Zulip):

As it stands, I think doing this currently would result in separate trace files.

simulacrum (Sep 19 2019 at 10:58, on Zulip):

hm, can polonius integrate into the rustc event system? maybe via a feature flag?

mw (Sep 19 2019 at 10:58, on Zulip):

well, everything goes through the Profiler object, right?

simulacrum (Sep 19 2019 at 10:58, on Zulip):

It sounds like we sort of want something similar to log and env_logger

Wesley Wiser (Sep 19 2019 at 10:59, on Zulip):

@mw yeah

simulacrum (Sep 19 2019 at 10:59, on Zulip):

though not necessarily decoupled so much

mw (Sep 19 2019 at 10:59, on Zulip):

so, any other crates would just need a way of taking a Profilerfrom the outside instead of instantiating their own

mw (Sep 19 2019 at 11:00, on Zulip):

the api is pretty much string based, so that would be no problem

Wesley Wiser (Sep 19 2019 at 11:01, on Zulip):

That's fair. I think there are some options currently, we just haven't really thought through them. It would be good to do so and have some documentation so that crates like polonius have a guide to integrating with measureme.

mw (Sep 19 2019 at 11:01, on Zulip):

@simulacrum, I think you are suggesting having some kind of "interface" crate (i.e. log) and then an implementation crate, right?

Wesley Wiser (Sep 19 2019 at 11:01, on Zulip):

But I don't think we need to talk about that right now.

simulacrum (Sep 19 2019 at 11:01, on Zulip):

Yes -- I agree to not needing to discuss right now

mw (Sep 19 2019 at 11:02, on Zulip):

I wonder if it would make sense to split out some of the stuff into measureme-interface

mw (Sep 19 2019 at 11:02, on Zulip):

but yes, let's table that for now

mw (Sep 19 2019 at 11:02, on Zulip):

alright, so I think that is the status of the MVP

mw (Sep 19 2019 at 11:02, on Zulip):

the two other things that come up are:

mw (Sep 19 2019 at 11:03, on Zulip):

1. people don't know how to use selfprofiling

mw (Sep 19 2019 at 11:03, on Zulip):

2. they want a feature that tells them where the compiler spends it's time (i.e. on what functions)

mw (Sep 19 2019 at 11:04, on Zulip):

topic 1, ergonomics, is pretty important, I think

mw (Sep 19 2019 at 11:04, on Zulip):

although, the MVP would take away some of the pressure because perf.rlo would do the hard stuff

mw (Sep 19 2019 at 11:05, on Zulip):

it's still rather important though :)

simulacrum (Sep 19 2019 at 11:05, on Zulip):

Personally for the ergonomics side I think it might be worth looping in Cargo folks, they've been doing some pretty good work with cargo -Ztiming and we might be able to integrate self-profile into that fairly easily (since Cargo knows about pids, etc)

Wesley Wiser (Sep 19 2019 at 11:05, on Zulip):

It's a small thing, but the rustc guide on profiling didn't mention -Z self-profile so I added a pointer to our docs https://rust-lang.github.io/rustc-guide/profiling.html

mw (Sep 19 2019 at 11:05, on Zulip):

interesting. I need to look up what cargo -Ztiming even is :)

Wesley Wiser (Sep 19 2019 at 11:06, on Zulip):

The -Ztiming flag is really cool

simulacrum (Sep 19 2019 at 11:06, on Zulip):

see e.g. benchmarks we definitely see being removed/added over time

simulacrum (Sep 19 2019 at 11:06, on Zulip):

er http://gistpreview.github.io/?4c9e55c90cc58a908b7074a551ce5a89

pnkfelix (Sep 19 2019 at 11:06, on Zulip):

how much do we care with parity with -Z time-passes, in terms of how much information is captured?

pnkfelix (Sep 19 2019 at 11:06, on Zulip):

I assume it doesn't really matter for MVP

pnkfelix (Sep 19 2019 at 11:06, on Zulip):

since people who want the -Z time-passes data can continue to use it

simulacrum (Sep 19 2019 at 11:06, on Zulip):

I think "not at all" personally, time-passes is sort of similar but queries are more precise

simulacrum (Sep 19 2019 at 11:07, on Zulip):

(at least, for parts where we have queries, and my understanding is we can approximate them for the areas where we don't with the current profiling infra

mw (Sep 19 2019 at 11:07, on Zulip):

nice! cargo -Ztiming definitely seems to overlap with what I had in mind for multi-crate self-profiling

pnkfelix (Sep 19 2019 at 11:08, on Zulip):

I guess my point is more that: If our plan is to eventually tear out the -Z time-passes code, then it might be good to first ensure that -Z self-profile is covering at least the important cases that -Z time-passes did (which may not necessarily mean all the cases it covers)

mw (Sep 19 2019 at 11:08, on Zulip):

yes

mw (Sep 19 2019 at 11:08, on Zulip):

we are in no hurry to remove -Ztime-passes though, I think

pnkfelix (Sep 19 2019 at 11:08, on Zulip):

but again, that does not seem to be a requirement for the MVP itself.

pnkfelix (Sep 19 2019 at 11:08, on Zulip):

okay, cool.

mw (Sep 19 2019 at 11:10, on Zulip):

so, I think the big task for ergonomics is coming up with a description of what ergonomic usage would even look like

mw (Sep 19 2019 at 11:10, on Zulip):

i.e. what is the workflow we want to have

mw (Sep 19 2019 at 11:10, on Zulip):

I don't think that is something we should discuss here in detail

mw (Sep 19 2019 at 11:11, on Zulip):

but it would be interesting to know if somebody would want to look into that

Wesley Wiser (Sep 19 2019 at 11:12, on Zulip):

I'd like to hear from people who've used or tried to use measureme before. We have a lot of data available now but we should know what people are trying to do with it. Is it just finding slow queries or are there other things our tools should optimize for?

mw (Sep 19 2019 at 11:13, on Zulip):

yes, that sounds smart :)

pnkfelix (Sep 19 2019 at 11:13, on Zulip):

so you mean do a general survey?

pnkfelix (Sep 19 2019 at 11:14, on Zulip):

(maybe on users.rlo ?)

Wesley Wiser (Sep 19 2019 at 11:14, on Zulip):

Are general rust users the target audience for measureme?

Wesley Wiser (Sep 19 2019 at 11:14, on Zulip):

(I assumed it would be more people hacking on rustc)

mw (Sep 19 2019 at 11:14, on Zulip):

internals might be the better venue

pnkfelix (Sep 19 2019 at 11:14, on Zulip):

oh I suppose its more an internals.rlo thing

simulacrum (Sep 19 2019 at 11:14, on Zulip):

I think at this point no, though we may want to pivot to that a little once we have the span-based tracking of cost

Wesley Wiser (Sep 19 2019 at 11:15, on Zulip):

I know a couple people have tried to use measureme but I don't know if they found it useful or not.

Wesley Wiser (Sep 19 2019 at 11:15, on Zulip):

@pnkfelix you mentioned using it to investigate incremental performance the other day

pnkfelix (Sep 19 2019 at 11:15, on Zulip):

yes

pnkfelix (Sep 19 2019 at 11:15, on Zulip):

i had to add more calls (events?) to get the data I needed

mw (Sep 19 2019 at 11:15, on Zulip):

I think it still makes sense to come up with a vision ourselves first, right?

Wesley Wiser (Sep 19 2019 at 11:16, on Zulip):

I know @nikomatsakis was trying to use it over the summer as well.

pnkfelix (Sep 19 2019 at 11:16, on Zulip):

(which is why I've been talking about the workflow for that)

mw (Sep 19 2019 at 11:16, on Zulip):

or rather a set of use-cases and then drill down into those

pnkfelix (Sep 19 2019 at 11:17, on Zulip):

that's a good point

mw (Sep 19 2019 at 11:17, on Zulip):

hm, coming up with the set of use cases might be something that would benefit from asking on internals

pnkfelix (Sep 19 2019 at 11:17, on Zulip):

in particular, I can imagine using this for comparing:

pnkfelix (Sep 19 2019 at 11:17, on Zulip):

1. two different versions of the compiler

mw (Sep 19 2019 at 11:17, on Zulip):

but, let's not forget, we are users too :)

pnkfelix (Sep 19 2019 at 11:17, on Zulip):

2. two runs of same compiler with different flags

pnkfelix (Sep 19 2019 at 11:17, on Zulip):

3. a single run of the compiler on some interesting benchmark

pnkfelix (Sep 19 2019 at 11:18, on Zulip):

4. I suppose one could also use it to observe two runs of same compiler with same flags on two variants of a fixed benchmark.

mw (Sep 19 2019 at 11:18, on Zulip):

shall we open a thread on internals, where we just publicly collect use cases?

pnkfelix (Sep 19 2019 at 11:18, on Zulip):

... does that sound ... plausibly exhaustive?

mw (Sep 19 2019 at 11:18, on Zulip):

and others can chime in

pnkfelix (Sep 19 2019 at 11:18, on Zulip):

fair enough.

simulacrum (Sep 19 2019 at 11:19, on Zulip):

I think opening a thread sounds good, though I do feel like that's pretty exhaustive :)

mw (Sep 19 2019 at 11:19, on Zulip):

I think concrete examples of problems people tried to investigate might still be helpful

mw (Sep 19 2019 at 11:19, on Zulip):

i.e. the use cases are still pretty abstract

mw (Sep 19 2019 at 11:20, on Zulip):

@Wesley Wiser, would you be up for starting that thread?

Wesley Wiser (Sep 19 2019 at 11:20, on Zulip):

Sure!

mw (Sep 19 2019 at 11:20, on Zulip):

excellent

mw (Sep 19 2019 at 11:20, on Zulip):

alright, we are at 50 minutes

mw (Sep 19 2019 at 11:21, on Zulip):

shall we talk about the other feature people want?

mw (Sep 19 2019 at 11:21, on Zulip):

i.e. assigning compilation time to specific items in your code?

Wesley Wiser (Sep 19 2019 at 11:21, on Zulip):

Yes, I think that's probably related to some of the feedback we're going to get on irlo

mw (Sep 19 2019 at 11:22, on Zulip):

I think that one would need quite a bit of planning

simulacrum (Sep 19 2019 at 11:22, on Zulip):

In some sense, we're already tracking it (or could be) as an "input" to queries via tcx.at(span).query(...)

mw (Sep 19 2019 at 11:22, on Zulip):

in some sense, yes :)

simulacrum (Sep 19 2019 at 11:23, on Zulip):

so one option might be to just dump all those spans into the data we're collecting and then dump the span table at compilation end or so

mw (Sep 19 2019 at 11:23, on Zulip):

it's still complicated though, because queries are cached

simulacrum (Sep 19 2019 at 11:23, on Zulip):

I would personally be really happy with an MVP that ignored incremental to start

mw (Sep 19 2019 at 11:23, on Zulip):

me too

mw (Sep 19 2019 at 11:23, on Zulip):

but queries are cached even in non-incremental mode

pnkfelix (Sep 19 2019 at 11:23, on Zulip):

sorry, what does "ignore incremental" mean?

pnkfelix (Sep 19 2019 at 11:24, on Zulip):

as in, you can't trust the output you get when incremental compilation is turned on?

simulacrum (Sep 19 2019 at 11:24, on Zulip):

it seems like we can just attribute to all spans loosely that a query is run with, right?

mw (Sep 19 2019 at 11:24, on Zulip):

query invocations form a directed acyclic graph

mw (Sep 19 2019 at 11:25, on Zulip):

I think this topic is too complicated for this meeting

Wesley Wiser (Sep 19 2019 at 11:25, on Zulip):

I think the issue is that if, for example, we ask for optimized_mir(foo) twice, the first time the query runs, it will take some amount of time. But the second time, it will already be cached in the DepGraph so it will be basically free.

Wesley Wiser (Sep 19 2019 at 11:25, on Zulip):

So counting all of the time for the first place that asked for the query and one for the second isn't correct.

Wesley Wiser (Sep 19 2019 at 11:26, on Zulip):

Because removing the first site might not actually improve compilation time.

mw (Sep 19 2019 at 11:26, on Zulip):

so, we know there is interest in this feature, but when do we want to spend time on it?

simulacrum (Sep 19 2019 at 11:26, on Zulip):

hm, but presumably it's rarely the case that the span changes across those two invocations?

simulacrum (Sep 19 2019 at 11:26, on Zulip):

I think it is sort of MVP 2.0

mw (Sep 19 2019 at 11:27, on Zulip):

yeah

pnkfelix (Sep 19 2019 at 11:27, on Zulip):

I think the issue is that if, for example, we ask for optimized_mir(foo) twice, the first time the query runs, it will take some amount of time. But the second time, it will already be cached in the DepGraph so it will be basically free.

Isn't this info incorporated into the presentation in some fashion? Or am I misremembering?

mw (Sep 19 2019 at 11:27, on Zulip):

yes, it is

mw (Sep 19 2019 at 11:28, on Zulip):

we can track of the whole graph, including cache hits

mw (Sep 19 2019 at 11:28, on Zulip):

the information is there, we just need to find out how to usefully interpret it

pnkfelix (Sep 19 2019 at 11:28, on Zulip):

so is this really a matter of improving the presentation, so that user expectations are managed better?

Wesley Wiser (Sep 19 2019 at 11:28, on Zulip):

I think it's mostly a matter of communicating that to the user

Wesley Wiser (Sep 19 2019 at 11:29, on Zulip):

Most people seem to want to see something like

$ summarize code-profile /path/to/rustc-results

Total time in rustc: 120 seconds

----------------------------------------
| % time | Item                        |
| ------ | -----------------------------
| 20.4%  | example::foo::bar::clone()  |
| 10.2%  | example::baz::widget::bla() |

(more rows)
Wesley Wiser (Sep 19 2019 at 11:30, on Zulip):

Accurately communicating where time was spent but also how to actually improve compilation time in such a simple format seems very difficult.

mw (Sep 19 2019 at 11:30, on Zulip):

the feature is pretty extensive, actually. a whole sub-product kindof

simulacrum (Sep 19 2019 at 11:30, on Zulip):

I also think most people might be okay with us not initially helping with the latter

simulacrum (Sep 19 2019 at 11:31, on Zulip):

Like, if I know the function then I can get LLVM IR, etc and do that work myself more readily

Wesley Wiser (Sep 19 2019 at 11:32, on Zulip):

I get the sense that (some) people want this to make changes to their code so it compiles faster. If we don't provide data that helps them achieve that, the tool won't be useful to them.

mw (Sep 19 2019 at 11:32, on Zulip):

would it be helpful to have a place where we can just collect ideas and thoughts about this feature?

mw (Sep 19 2019 at 11:33, on Zulip):

but where? :)

mw (Sep 19 2019 at 11:34, on Zulip):

GH issue?

mw (Sep 19 2019 at 11:34, on Zulip):

topic here ?

simulacrum (Sep 19 2019 at 11:34, on Zulip):

Maybe a dedicated repo? Similar to unsafe code guidelines etc

Wesley Wiser (Sep 19 2019 at 11:34, on Zulip):

Is this feature on topic for the irlo post?

simulacrum (Sep 19 2019 at 11:34, on Zulip):

I think that has worked well for us as a community

mw (Sep 19 2019 at 11:34, on Zulip):

@Wesley Wiser, not quite

mw (Sep 19 2019 at 11:35, on Zulip):

although it will probably come up

Wesley Wiser (Sep 19 2019 at 11:35, on Zulip):

(There is an issue for the feature here https://github.com/rust-lang/measureme/issues/51)

simulacrum (Sep 19 2019 at 11:35, on Zulip):

We could discuss on that issue for now

mw (Sep 19 2019 at 11:35, on Zulip):

@simulacrum , in that repo, where would the discussion happen?

simulacrum (Sep 19 2019 at 11:36, on Zulip):

Issues for the most part

mw (Sep 19 2019 at 11:36, on Zulip):

yes, let's stick to the existing GH issue for now

mw (Sep 19 2019 at 11:37, on Zulip):

and ask folks like @nikomatsakis to post their wishlist/ideas there

mw (Sep 19 2019 at 11:38, on Zulip):

alright, does everybody feel that they've got enough action items for the immediate future?

mw (Sep 19 2019 at 11:38, on Zulip):

I have the event review + PR for me

simulacrum (Sep 19 2019 at 11:39, on Zulip):

I think so

mw (Sep 19 2019 at 11:39, on Zulip):

perf.rlo updates for @simulacrum and @Wesley Wiser

pnkfelix (Sep 19 2019 at 11:39, on Zulip):

(my action item is to start the pre-triage for the rustc meeting. oh wait, that's probably not what you meant)

mw (Sep 19 2019 at 11:39, on Zulip):

@Wesley Wiser will post about ergonomics on internals

Wesley Wiser (Sep 19 2019 at 11:39, on Zulip):

I'll post the irlo thread, write up meeting notes, and work with @simulacrum on perf.rlo

pnkfelix (Sep 19 2019 at 11:40, on Zulip):

((i will try to at least provide feedback on my own user case on the internals post))

mw (Sep 19 2019 at 11:40, on Zulip):

@pnkfelix, very good!

mw (Sep 19 2019 at 11:41, on Zulip):

if you want to be extra helpful then you could also describe there how using self-profiling would have looked like in the ideal world for your use case

mw (Sep 19 2019 at 11:44, on Zulip):

/me merges back into PGO debugging for the rest of the week :ghost:

mw (Sep 19 2019 at 11:44, on Zulip):

thanks for attending the meeting everyone !!! :heart:

Wesley Wiser (Sep 19 2019 at 11:44, on Zulip):

:wave:

Wesley Wiser (Sep 19 2019 at 14:30, on Zulip):

Posted on irlo https://internals.rust-lang.org/t/compiler-profiling-survey/10969

Last update: Nov 15 2019 at 20:05UTC