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

Jump to bottom

[SR-2902] Add a timer and debug flag for expression type checking #45496

Closed
swift-ci opened this issue Oct 9, 2016 · 3 comments
Closed

[SR-2902] Add a timer and debug flag for expression type checking #45496

swift-ci opened this issue Oct 9, 2016 · 3 comments
Labels
compiler The Swift compiler in itself improvement

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Oct 9, 2016

Previous ID SR-2902
Radar None
Original Reporter benasher44 (JIRA User)
Type Improvement
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Improvement
Assignee None
Priority Medium

md5: c42786dc94b80bebe7ff685f51ac0207

Issue Description:

This could be useful to help further debug compile time slowness by giving developers the tools to identify and report common slow-to-type-check expressions in their codebases. It would likely be another flag similar to `debug-time-function-bodies`.

From Mark Lacy in this swift-dev thread:

…There are a few places that might make sense for this, but I suspect ConstraintSystem::solve() might be the best. This is ultimately called from a variety of places, and would provide the most insight into where time is being spent in the expression type checking. It’s possible something higher up the stack, like TypeChecker::solveForExpression or TypeChecker::typeCheckExpression() might make more sense as well. You can model this on how -debug-time-function-bodies is currently implemented, e.g. look at swift::performTypeChecking for some help on getting started.…
@modocache
Copy link
Mannequin

modocache mannequin commented Nov 11, 2017

This issue was created in October 2016. @rudkx added -warn-long-expression-type-checking= in d26c8592222, a commit from June 2017. I think that option takes care of the feature described in this task.

Maybe it also makes sense to add a -debug-time-expression-time-checking option, similar to -debug-time-function-bodies, which would allow developers to see the time it takes to type-check all expressions – but I imagine they could just as easily run -warn-long-expression-type-checking=1.

Maybe this task could be marked as "resolved"?

@swift-ci
Copy link
Collaborator Author

Comment by Ben A (JIRA)

I agree. This is resolved to me!

@rudkx
Copy link
Member

rudkx commented Nov 11, 2017

Note that `-debug-time-expression-type-checking` was added in #6729 (months before the warning option was added).

There is also `-solver-expression-time-threshold=<time in seconds>` which tells the expression type checker to give up after that amount of time. The threshold defaults to 60s, which is a very long time but was made that way in order to allow unoptimized builds and builds with instrumentation to not time out on reasonable (though still very long) type checking times. The non-time-based thresholds of memory usage, etc. that were in place before still apply - this is just an extra "backup" method so that people aren't waiting really long times thinking their build is going to eventually complete.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compiler The Swift compiler in itself improvement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@rudkx @swift-ci