Moved to a separate thread per request.
Original comment
There definitely are situations where the compiler can outline complex values directly into the data segment of the binary, but I don't know what the limitations are. For example, this example (godbolt) with a simple Int and String struct gets converted to a data blob:
output.staticArray : [output.Foo]:
.zero 8
mainTv_:
.zero 8
.zero 16
.quad 6
.quad 12
.quad 10
.quad 7234932
.quad -2089670227099910144
.quad 20
.quad 133540975310708
.quad -1873497444986126336
.quad 30
.quad 133541042677876
.quad -1873497444986126336
.quad 100
.quad 7236850741311532655
.quad -1513209474789907086
.quad 1000
.quad 8462097072821464687
.quad -1441151879073603213
.quad 100000
.quad -3458764513820540908
.quad .L__unnamed_1+9223372036854775776
.L__unnamed_1:
.asciz "one hundred thousand"
...where the code to initialize it consists only of a type metadata lookup and then a call to swift_initStaticObject, which appears to be fast—it just populates the runtime metadata pointer at the beginning of the inlined data.
One cool thing about this is that I was able to use Strings instead of StaticStrings and it still worked—and in fact, the strings that could fit into the small string representation used that instead of using a pointer to separate character data.
I'm not sure what it is about OptionSets that prevents this from working, though. I think this happens as part of the ObjectOutliner SILOptimizer pass in the compiler, so that would be the place to improve.
The other drawback about this is that since it's an optimization pass, unoptimized builds will still get the slow code path that initializes everything at runtime. I wonder if this transformation could happen as a mandatory pass, so that debug builds could still rely on static data.