Resolve some test issues

apple / swift-atomics

Low-level atomic operations for Swift

Apache License 2.0

1.06k stars 50 forks source link

Resolve some test issues #71

Closed lorentey closed 1 year ago

lorentey commented 1 year ago

Disable test registration outside of CMake builds.

This will allow this code base to be built with build systems other than CMake and SPM without these test manifests suddenly appearing again.
Split Basics.swift.gyb into 26 different files, one for each test case.

The original autogenerated swift file is so humongous that it causes problems for some folks.
Fix CMake configuration for package tests.

Checklist

[X] I've read the Contribution Guidelines
[X] My contributions are licensed under the Swift license.
[X] I've followed the coding style of the rest of the project.
[ ] I've added tests covering all new code paths my change adds to the project (if appropriate).
[X] I've verified that my change does not break any existing tests.
[ ] I've updated the documentation if necessary.

lorentey commented 1 year ago

@swift-ci test

lorentey commented 1 year ago

@swift-ci test

lorentey commented 1 year ago

@swift-ci test

lorentey commented 1 year ago

@swift-ci test

lorentey commented 1 year ago

Wow. Splitting up that huge test file reduced CI build times from around 10 minutes to roughly 1 minute, on both macOS and Linux. 🤯

lorentey commented 1 year ago

@swift-ci test

lorentey commented 1 year ago

Compiling this one file probably needed too much memory for the CI machines, and so they started thrashing, leading to 10x slower build times than expected.

This also explains the off hand comments I sometimes saw about not being able to build tests at all on constrained machines -- sadly I can't recall any actual bug reports about that, so it remained undiagnosed.

tayloraswift commented 1 year ago

Wow. Splitting up that huge test file reduced CI build times from around 10 minutes to roughly 1 minute, on both macOS and Linux. exploding_head

this whole time i thought the problem was vague type inference… i did not know source file length could have such an impact on typechecker performance…

lorentey commented 1 year ago

I suspect it's all about the sheer amount of memory that the compiler needed to hold the whole thing all at once. This also explains why I never really saw this in my local builds -- I don't typically try building things on memory-constrained systems.