Skip to content

[ConstraintGraph] Fix contractEdges to gather constraints only once #16560

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

Merged
merged 2 commits into from
May 14, 2018

Conversation

xedin
Copy link
Contributor

@xedin xedin commented May 11, 2018

Currently we have this non-optimal behavior in contractEdges where
for every type variable it gathers constraints for its whole equivalence
class before checking if any are "contractable", instead constraints
could be gathered/filtered once which removes a lot of useless work.

@xedin xedin requested a review from rudkx May 11, 2018 22:17
@xedin
Copy link
Contributor Author

xedin commented May 11, 2018

@swift-ci please test

@xedin
Copy link
Contributor Author

xedin commented May 11, 2018

@swift-ci please smoke test compiler performance

@xedin
Copy link
Contributor Author

xedin commented May 11, 2018

@swift-ci please test source compatibility

Copy link
Contributor

@rudkx rudkx left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

How much does this speed up type checking cases like SR-7632?

Currently we have this non-optimal behavior in `contractEdges` where
for every type variable it gathers constraints for its whole equivalence
class before checking if any are "contractable", instead constraints
could be gathered/filtered once which removes a lot of useless work.
@slavapestov
Copy link
Contributor

Can we add a scale_test for this?

@xedin
Copy link
Contributor Author

xedin commented May 11, 2018

@slavapestov I will try, but the problem is that we don't really have a good counter right now to measure the effect at the moment...

@xedin
Copy link
Contributor Author

xedin commented May 11, 2018

FYI I've tried with 25k element array of ints e.g. let _: [Int] = [1, 2, 3, ...] without changes it takes ~45 secs. to type-check, with changes it only takes ~500 milliseconds.

@swift-ci
Copy link
Contributor

Build comment file:

Summary for master smoketest

Unexpected test results, excluded stats for ReactiveCocoa

No regressions above thresholds

Debug

debug brief

Regressed (0)
name old new delta delta_pct
Improved (0)
name old new delta delta_pct
Unchanged (delta < 1.0% or delta < 100.0ms) (2)
name old new delta delta_pct
LLVM.NumLLVMBytesOutput 41,247,170 41,251,490 4,320 0.01%
time.swift-driver.wall 70.1s 69.4s -666.3ms -0.95%

debug detailed

Regressed (0)
name old new delta delta_pct
Improved (0)
name old new delta delta_pct
Unchanged (delta < 1.0% or delta < 100.0ms) (23)
name old new delta delta_pct
AST.NumImportedExternalDefinitions 84,556 84,556 0 0.0%
AST.NumLoadedModules 12,956 12,956 0 0.0%
AST.NumTotalClangImportedEntities 256,399 256,399 0 0.0%
AST.NumUsedConformances 8,766 8,766 0 0.0%
IRModule.NumIRBasicBlocks 125,749 125,749 0 0.0%
IRModule.NumIRFunctions 75,153 75,153 0 0.0%
IRModule.NumIRGlobals 68,675 68,675 0 0.0%
IRModule.NumIRInsts 1,429,975 1,429,975 0 0.0%
IRModule.NumIRValueSymbols 128,737 128,737 0 0.0%
LLVM.NumLLVMBytesOutput 41,247,170 41,251,490 4,320 0.01%
SILModule.NumSILGenFunctions 42,746 42,746 0 0.0%
SILModule.NumSILOptFunctions 47,119 47,119 0 0.0%
Sema.NumConformancesDeserialized 357,780 357,780 0 0.0%
Sema.NumConstraintScopes 900,349 900,349 0 0.0%
Sema.NumDeclsDeserialized 2,105,817 2,105,817 0 0.0%
Sema.NumDeclsValidated 190,411 190,411 0 0.0%
Sema.NumFunctionsTypechecked 48,042 48,042 0 0.0%
Sema.NumGenericSignatureBuilders 81,719 81,719 0 0.0%
Sema.NumLazyGenericEnvironments 419,438 419,438 0 0.0%
Sema.NumLazyGenericEnvironmentsLoaded 39,199 39,199 0 0.0%
Sema.NumLazyIterableDeclContexts 335,845 335,845 0 0.0%
Sema.NumTypesDeserialized 2,326,130 2,326,130 0 0.0%
Sema.NumTypesValidated 211,820 211,820 0 0.0%

Release

release brief

Regressed (0)
name old new delta delta_pct
Improved (0)
name old new delta delta_pct
Unchanged (delta < 1.0% or delta < 100.0ms) (2)
name old new delta delta_pct
LLVM.NumLLVMBytesOutput 30,117,892 30,117,888 -4 -0.0%
time.swift-driver.wall 144.6s 143.8s -818.5ms -0.57%

release detailed

Regressed (0)
name old new delta delta_pct
Improved (0)
name old new delta delta_pct
Unchanged (delta < 1.0% or delta < 100.0ms) (23)
name old new delta delta_pct
AST.NumImportedExternalDefinitions 8,764 8,764 0 0.0%
AST.NumLoadedModules 406 406 0 0.0%
AST.NumTotalClangImportedEntities 25,373 25,373 0 0.0%
AST.NumUsedConformances 8,772 8,772 0 0.0%
IRModule.NumIRBasicBlocks 158,940 158,940 0 0.0%
IRModule.NumIRFunctions 57,180 57,180 0 0.0%
IRModule.NumIRGlobals 56,040 56,040 0 0.0%
IRModule.NumIRInsts 1,324,447 1,324,447 0 0.0%
IRModule.NumIRValueSymbols 101,904 101,904 0 0.0%
LLVM.NumLLVMBytesOutput 30,117,892 30,117,888 -4 -0.0%
SILModule.NumSILGenFunctions 22,151 22,151 0 0.0%
SILModule.NumSILOptFunctions 36,626 36,626 0 0.0%
Sema.NumConformancesDeserialized 96,575 96,575 0 0.0%
Sema.NumConstraintScopes 799,066 799,066 0 0.0%
Sema.NumDeclsDeserialized 210,458 210,458 0 0.0%
Sema.NumDeclsValidated 59,864 59,864 0 0.0%
Sema.NumFunctionsTypechecked 10,695 10,695 0 0.0%
Sema.NumGenericSignatureBuilders 9,657 9,657 0 0.0%
Sema.NumLazyGenericEnvironments 33,020 33,020 0 0.0%
Sema.NumLazyGenericEnvironmentsLoaded 4,534 4,534 0 0.0%
Sema.NumLazyIterableDeclContexts 21,143 21,143 0 0.0%
Sema.NumTypesDeserialized 277,755 277,755 0 0.0%
Sema.NumTypesValidated 34,806 34,806 0 0.0%

@slavapestov
Copy link
Contributor

@xedin You should just add a new counter that would be quadratic without this change. I think it’s important to test this so we don’t regress in the future.

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@slavapestov Yeah, I'm trying to figure out what might it be, maybe it should be "num constraints considered by each contraction run", that metric would grown much slower comparing to before, it would be number or scopes * total number of constraints in scope, when it used to be number of scopes * num type vars * num of constraints in scope.

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@graydon Could you please take a look at statistics changes? I wonder why I get No data when I run new scale test I added, I did everything exactly like incrementScopeCounter...

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

I wonder if that’s because that particular test would actually never find any contractable constraints... I will try putting it in find since that actual iteration.

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@swift-ci please source compatibility

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@swift-ci please source compatibility

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@swift-ci please test

@swift-ci
Copy link
Contributor

Build failed
Swift Test Linux Platform
Git Sha - 9a99897b5c2885becbcc0a8802dafb7896eb9047

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 9a99897b5c2885becbcc0a8802dafb7896eb9047

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@swift-ci please smoke test macOS platform

@xedin
Copy link
Contributor Author

xedin commented May 12, 2018

@swift-ci please test macOS platform

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants