FWIW we had a few in-person discussions on this topic, but apparently none of them surfaced here.
First of all:
Wouldn't it make a great starting point to a hypothetical "How to reduce performance bugs" article!
There is an amazing document on how to measure compiler performance. Substitute "compiler" to "your program" there and a big part of the document still applies.
As for the discussions and the overall suggestion. I could not agree more that the performance problems should be reported and looked at. It is a matter of making these reports useful and used.
I can categorize reports into 3 categories:
- Potential performance problem that can also be just a misunderstanding of the complexity guarantees or compiler inter-workings.
- Confirmed performance problems that are however not reduced to a minimal case.
- Reduced cases where the performance problems manifests itself.
The most obvious choice for the 3rd category of problems would be to just add them as PRs to the Swift benchmark suite. It is believed (by me) to not be hard to integrate benchmarks into that suite. We are very interested in more benchmarks that cover real-world scenarios, therefore such PRs don't have to be perfect, just something that shows the problem. We can improve/integrate that separately.
Next goes the non-reduced examples. I think these should be filed as bugs since they are confirmed. I would not mind at all if the new topic is started on swift-users with a special tag with a "call for reduction". This would cover category number 2.
Category number 1 in my opinion is something that can be discussed on the forum, as it can be beneficial to many people. I would expect at least some of these problems to be due to misunderstanding, and as such, the forum post would become a kind of documentation.
Personally, I don't think we really need a separate category, the tag would do.
Does it make sense? If so, we can ask @Nicole_Jacque to create this tag.