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

Re-add time-passes to the collected data #147

Closed
Mark-Simulacrum opened this issue Sep 6, 2017 · 5 comments
Closed

Re-add time-passes to the collected data #147

Mark-Simulacrum opened this issue Sep 6, 2017 · 5 comments

Comments

@Mark-Simulacrum
Copy link
Member

It would be good to get opinions from the compiler team. I expected effectively nonexistent demand, but so far both @arielb1 and @eddyb have requested it for the runs I've done on PRs, so maybe it'd be worth re-adding. I could see us adding it only into the comparison view, where you could switch to a specific crate being shown and then you'd see the passes for it. Timing data has fluctuated too much (and still does) in the past for it to be worth it though I think.

cc @michaelwoerister @alexcrichton @nikomatsakis: What are your thoughts?

@alexcrichton
Copy link
Member

I was under the impression that "passes" as we know them today are basically going away in the compiler anyway so we wouldn't want to track this over time regardless. It may be worthwhile, though, investigating the ability to profile queries, as in the "near future" I'd imagine that everything is structured as a query?

@Mark-Simulacrum
Copy link
Member Author

Hm, well, I'd certainly be willing to add queries to the data we collect. However, it looks to me that they are as prone (or even more so) to change names and meanings over time, and as such are unstable for long-term tracking. However, when comparing PR to PR (e.g. @bors try runs) perhaps that's not too large a problem. Perhaps we could implement some form of high-level view on queries: maybe something like start -> HIR construction, HIR built, typeck, mir building, borrowck, llvm passes. These are largely drawn out of the air -- I don't really know what's meaningful to keep track of and permanent enough to not change meaning overly much over time.

@nikomatsakis
Copy link

I am personally against adding tooling for time-passes, which I consider a dated concept. I believe that query-profiling data would probably be useful though. To me, though, I'd consider this lower priority versus getting benchmarks of the generated code up and going.

@nikomatsakis
Copy link

It's true that query names do change though. But how much does that matter? I imagine typically you'd just want to view the composition of a single run in terms of the queries in which it spent its time -- you can compare "by eye" across runs, you're basically just looking for gross discrepancies there. The human can adjust for the different names (which are unlikely anyway as long as the two runs are close together in time).

@Mark-Simulacrum
Copy link
Member Author

Okay, so I take it that time-passes seems like a bad idea due to being dated. With query-profiling data, I'd be open to adding it, but will need to read up on what that means: I'm not entirely familiar with it as a concept. I think we can definitely do something with it, maybe even just having the HTML files that I believe it generates available for perusal for all benchmarks on perf.rlo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants