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
[SR-2741] Provide Structured Output Of debug-time-function-bodies #45345
Comments
/cc @belkadan. Maybe we could hook this up to the serialized diagnostics consumer...? I'd be interested in taking this task on, so if you have any tips I'd love to hear them. |
I'm leery of "productizing" -debug-time-function-bodies in any way because it's already not a true story. Import and decl-checking costs that come up for the first time during a particular function get ascribed to that function. SILGen, optimization, and LLVM costs are ignored entirely. Decl-checking costs that are not within a particular function are also ignored. The only useful purpose of -debug-time-function-bodies is to see if the type checker is spinning on a particular function. |
Comment by Brian Michel (JIRA) @belkadan yeah I totally understand this is a debug option (it's even in the name!), but I guess I'm unsure what else to do to keep an eye on Swift compile times in larger applications across an entire team of engineers. Granted, we've already somewhat built tooling around this here, https://github.com/tumblr/SwiftCompilationPerformanceReporter, it'd be nice to see this as a first class feature. I would understand that if the larger conversation should be around how to not get into these slow compile paths, or totally eliminating these kinds of possibilities elsewhere in the compiler, but those seems like very long term conversations. I'm also not sure how widespread this problem actually is. We at Tumblr have certainly experienced this, but maybe we're a one off. Would love to hear more of your thoughts on the matter. |
I've seen a fair amount of "how to figure out what's slowing down your Swift compile times" blog posts: I think providing structured output to analyze compilation times would help brianmichel (JIRA User) and many others. Maybe
I agree. I also think these tools would help end users discover situations that lead to slow compilation times, so that they can submit Swift reports for those situations. |
Additional Detail from JIRA
md5: 2b0d14b89fce57f3a471a2e44343479a
Issue Description:
Right now when a user runs the Swift compiler with the
debug-time-function-bodies
parameter the important output yielded by this parameter is dumped inline with the rest of the build information similar to the following:This means that in order to extract the information relevant to compile time complexity, each end user must craft some sort of output parsing logic to extract the relevant logs while not breaking them at the same time.
I'd like if the Swift compiler was able to accept an option to output the
debug-time-function-bodies
into a structured data format like XML to make it easy to both locate and parse this data in a machine friendly ways (like for continuous integration environments)The text was updated successfully, but these errors were encountered: