Open swift-ci opened 8 years ago
ec882e32-f2b6-4d2a-849c-98d6c7df0cfb
commented
8 years ago /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. 🙂
belkadan
commented
8 years ago 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.
swift-ci
commented
8 years ago 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.
ec882e32-f2b6-4d2a-849c-98d6c7df0cfb
commented
8 years ago 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 -debug-time-function-bodies isn't the best data to format. In that case, perhaps we can provide formatting for a different format (-driver-time-compilation?), or add options for other interesting profile data.
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 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
| | | |------------------|-----------------| |Votes | 0 | |Component/s | Compiler | |Labels | New Feature | |Assignee | None | |Priority | Medium | md5: 2b0d14b89fce57f3a471a2e44343479aIssue Description:
Right now when a user runs the Swift compiler with the
debug-time-function-bodiesparameter 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-bodiesinto 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)