Use optimize for size

[noahsmartin]

OSize is the standard optimization level that most apps prioritizing performance would use, from the Swift Optimization Tips:

-Osize: This is meant for most production code. The compiler performs aggressive optimizations that can drastically change the type and amount of emitted code. Debug information will be emitted but will be lossy.
-O: This is a special optimization mode where the compiler prioritizes performance over code size.

Usually -O ends up being slower than -Osize because there ends up being extra memory accesses since the code is spread out in more memory, even though there are fewer CPU instructions. The same reason that order files speed up code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 86.667%. Comparing base (de86244) to head (fd97cec).
Report is 7 commits behind head on main.

✅ All tests successful. No failed tests found.

Additional details and impacted files

@@              Coverage Diff              @@
##              main     #5721       +/-   ##
=============================================
+ Coverage   86.212%   86.667%   +0.454%     
=============================================
  Files          422       422               
  Lines        36033     36091       +58     
  Branches     15222     16983     +1761     
=============================================
+ Hits         31065     31279      +214     
+ Misses        4926      4765      -161     
- Partials        42        47        +5     

see 36 files with indirect coverage changes

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update de86244...fd97cec. Read the comment docs.

[github-actions]

Performance metrics 🚀

	Plain	With Sentry	Diff
Startup time	1218.88 ms	1251.61 ms	32.73 ms
Size	23.75 KiB	903.94 KiB	880.20 KiB

Baseline results on branch: main

Startup times

Revision	Plain	With Sentry	Diff
079bcc8	1217.88 ms	1234.88 ms	17.00 ms
d7461dc	1233.69 ms	1255.29 ms	21.60 ms
2691350	1224.92 ms	1255.82 ms	30.90 ms
f92cfa9	1217.94 ms	1240.06 ms	22.12 ms
53b722c	1222.33 ms	1244.90 ms	22.56 ms
43597ba	1214.88 ms	1243.52 ms	28.65 ms
d637379	1226.43 ms	1250.77 ms	24.34 ms
a2a3bfb	1227.94 ms	1261.26 ms	33.32 ms
bce9765	1229.42 ms	1243.49 ms	14.07 ms
7c7ac56	1225.90 ms	1250.22 ms	24.33 ms

App size

Revision	Plain	With Sentry	Diff
079bcc8	23.74 KiB	874.07 KiB	850.33 KiB
d7461dc	23.75 KiB	874.45 KiB	850.70 KiB
2691350	23.75 KiB	850.73 KiB	826.98 KiB
f92cfa9	23.75 KiB	855.38 KiB	831.63 KiB
53b722c	23.75 KiB	906.08 KiB	882.33 KiB
43597ba	23.75 KiB	880.32 KiB	856.58 KiB
d637379	23.75 KiB	855.38 KiB	831.63 KiB
a2a3bfb	23.75 KiB	872.67 KiB	848.92 KiB
bce9765	23.74 KiB	874.06 KiB	850.32 KiB
7c7ac56	23.75 KiB	902.49 KiB	878.74 KiB

Previous results on branch: useOptimizeForSize

Startup times

Revision	Plain	With Sentry	Diff
bdc3949	1229.81 ms	1247.15 ms	17.34 ms

App size

Revision	Plain	With Sentry	Diff
bdc3949	23.75 KiB	903.95 KiB	880.20 KiB

[armcknight]

interesting. I guess -O is better in niche cases where certain hot paths can be optimized separately, as a next step before dropping down to assembly.