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

Instruments vs Xcode #113

Closed
oscbyspro opened this issue May 13, 2023 · 4 comments
Closed

Instruments vs Xcode #113

oscbyspro opened this issue May 13, 2023 · 4 comments

Comments

@oscbyspro
Copy link
Owner

oscbyspro commented May 13, 2023

As noticed in (#109), the measurements of Instruments' time profiler and Xcode's xctestplan are completely different. It's frustrating, because I cannot use the former to see why the latter takes so long. Ideally, I would just measure some real-world use case, but I haven't gotten around to replacing my arbitrary precision solution yet. As an example, the following takes 8.18 seconds with Instruments' time profiler but 54.5 seconds with Xcode's xctestplan:

func testDividingFullWidth() {
    var lhs = _blackHoleIdentity((UInt256.max))
    var rhs = _blackHoleIdentity((UInt256.max, UInt256.max))
    
    for _ in 0 ..< 100_000_000 {
        _blackHole(lhs.dividingFullWidth(rhs))
        _blackHoleInoutIdentity(&lhs)
        _blackHoleInoutIdentity(&rhs)
    }
}

Edit: I'm aware that this is an overflowing example. It mirrors Swift's standard semantics:

UInt.max.dividingFullWidth((UInt.max, UInt.max)) // truncating semantics, no crash
@oscbyspro oscbyspro added the help please send help :( label May 13, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented May 13, 2023

I'm hoping Instruments is correct on this one, not so much because it's faster, but because the xctestplan measurements make pointers seem unusable. Like, single digit addition (pointer-based) appears somewhat faster than full-width addition with Instruments' time profiler, but 2x slower with Xcode's xctestplan.

@oscbyspro oscbyspro added bug please fix this :( and removed bug please fix this :( labels May 13, 2023
@oscbyspro oscbyspro changed the title Instruments' time profiler vs Xcode's xctestplan Instruments' time profiler May 13, 2023
@oscbyspro oscbyspro changed the title Instruments' time profiler Performance profile: Instruments vs Xcode May 13, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented May 13, 2023

So, after seven eternities, I found the xctestplan option that matters:

xctestplan code coverage: on/off

Does anyone know what it does? Leaving it switched on ruins performance.

@oscbyspro oscbyspro changed the title Performance profile: Instruments vs Xcode Instruments' time profiler vs Xcode's xctestplan May 13, 2023
@oscbyspro
Copy link
Owner Author

oscbyspro commented May 13, 2023

I found this comment from  at developer.apple.com:

Note: Code coverage data collection incurs a performance penalty. Whether the penalty is significant or not, it should affect execution of the code in a linear fashion so performance results remain comparable from test run to test run when it is enabled. However, you should consider whether to have code coverage enabled when you are critically evaluating the performance of routines in your tests.

@oscbyspro oscbyspro removed the help please send help :( label May 13, 2023
@oscbyspro
Copy link
Owner Author

Hm, the mystery is solved. I find it strange, however, that it was enabled by default. I've not had that problem before.

@oscbyspro oscbyspro changed the title Instruments' time profiler vs Xcode's xctestplan Instruments vs Xcode May 13, 2023
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

No branches or pull requests

1 participant