4 ms·
Ah. Yeah, that could be. I'd still definitely clarify that in the post if that were what they meant.
by ragnese 5y ago
Ah. Yeah, that could be. I'd still definitely clarify that in the post if that were what they meant.
- glhaynes 5y agoIf that's the case, it's not clear to me that it shouldn't crash the app (versus the alternative of likely corrupting data) in release builds. I guess this is similar to the "assertions should/should not be turned on in release builds" debate, which IMO has good points on both sides. But maybe there's an extra complicating factor of TSan causing significant performance penalties making it impractical for it to be on in release builds?
- AJRF 5y agoYeah according to Apple TSan introduces from 2x to 20x slowdown
- ragnese 5y agoDon't get me wrong- I agree with the sentiment that crashes are better than corruption. But, as someone else already mentioned, the thread sanitizer does cause significant overhead from all of the debug info it holds (maybe a release version could just be performance tuned). But, also, Swift already has asserts that go away in release builds, as you mentioned. So it's at least consistent.