Stream: t-compiler/wg-prioritization

Topic: I-prioritize #71861 vec macro into_boxed codegen regression


triagebot (May 03 2020 at 21:07, on Zulip):

@WG-prioritization issue #71861 has been requested for prioritization.

Santiago Pastorino (May 04 2020 at 21:28, on Zulip):

hmmm I wonder how bad should we consider this one

Santiago Pastorino (May 04 2020 at 21:29, on Zulip):

in particular I guess it would be nice to see how bad some real world code would perform because of this issue

Santiago Pastorino (May 04 2020 at 21:30, on Zulip):

with the given information I'd say P-high at least :)

Santiago Pastorino (May 04 2020 at 21:31, on Zulip):

@WG-prioritization this is the only one missing prioritization right now :)

LeSeulArtichaut (May 05 2020 at 06:58, on Zulip):

It seems like the kind of issues that don’t only appear specifically with vec![0; n].into_boxed_slice(), right?

LeSeulArtichaut (May 05 2020 at 06:59, on Zulip):

I’d also say P-high

o0Ignition0o - Jeremy Lempereur (May 05 2020 at 07:16, on Zulip):

P-High sounds good to me as well!

Santiago Pastorino (May 05 2020 at 11:21, on Zulip):

P-high for now then if someone feels it should have a different priority we can discuss here :)

triagebot (May 05 2020 at 11:22, on Zulip):

Issue #71861's prioritization request has been removed.

Wesley Wiser (May 05 2020 at 13:30, on Zulip):

I'm ok with P-high but I think personally this is more of a P-medium issue. As far as I can tell, nothing is actually broken by this, it's just less efficient. If this was preventing somebody from using Rust on a embedded device or something, then I'd say P-high but as it is, it just seems like an optimization issue. We have lots of those :slight_smile:

Santiago Pastorino (May 05 2020 at 13:31, on Zulip):

@Wesley Wiser completely agree

Santiago Pastorino (May 05 2020 at 13:32, on Zulip):

but a performance issue in my opinion could totally be even P-critical

Santiago Pastorino (May 05 2020 at 13:32, on Zulip):

imagine a fn main() { println!("hi"); } program taking a minute to execute, I'd say that's P-critical

Santiago Pastorino (May 05 2020 at 13:33, on Zulip):

that's why I've mentioned, I guess it depends on how bad is the regression on real world cases

Santiago Pastorino (May 05 2020 at 13:33, on Zulip):

should we ask for that? should we ping cleanup crew to find that out?

Santiago Pastorino (May 05 2020 at 13:34, on Zulip):

Santiago Pastorino said:

imagine a fn main() { println!("hi"); } program taking a minute to execute, I'd say that's P-critical

but in particular also, I'd like to know if you @Wesley Wiser agree with me on this thing :)

Wesley Wiser (May 05 2020 at 13:35, on Zulip):

Yeah, I'd agree with that!

Wesley Wiser (May 05 2020 at 13:35, on Zulip):

Having read through the URLO IRLO post, I don't think that's the case though :slight_smile:

Wesley Wiser (May 05 2020 at 13:37, on Zulip):

I think, to your point, we need to also consider how important the code in question is. In any given release, we're going to regress some things and improve some other things. For most of that code, it doesn't really matter as long as it's not egregious.

Wesley Wiser (May 05 2020 at 13:38, on Zulip):

This doesn't feel like a critical part of the std lib where the difference in reported code size matters.

Wesley Wiser (May 05 2020 at 13:38, on Zulip):

As far as I can tell, nobody is actually complaining that the performance is bad, just that the code size is large.

Wesley Wiser (May 05 2020 at 13:45, on Zulip):

Any way, it seems that we're mostly on the same page. I think in the absence of evidence that this is causing a performance issue, I would lean toward P-medium.

Santiago Pastorino (May 05 2020 at 13:51, on Zulip):

agreed :+1:

Santiago Pastorino (May 05 2020 at 13:51, on Zulip):

let's make it P-medium

Last update: Jun 05 2020 at 21:15UTC