proposal: make a bunch of stuff inlinable

[lukaskollmer]

Current Situation

effectively none of the APIs in FHIRModels can be inlined by apps/packages using the FHIRModels package. this is can become very painful, especially e.g. when creating a lot of FHIRPrimitives where the underlying value is just a copy of the input (eg: FHIRString, FHIRURI, FHIRDecimal, etc.)

context: our application's primary use case for FHIRModels is creating Observations (and via that a bunch of other FHIR types), which then get JSON-encoded and uploaded to a server. (we also sometimes use the package to decode and inspect data, but that's a tiny minority of our usage.) it's not uncommon for our app to create millions of FHIR samples per day; as a result the lack of inlinability does actually have a significant and easily noticable impact on our app's performance.

Suggested Solution

i'd like to propose Apple consider marking as much of the FHIRModels package's public API as possible as @inlinable:

• all trivial operations on FHIRPrimitive and its companion types (FHIRString, FHIRURI, FHIRDecimal, FHIRInteger, etc)
  • initializers
  • equatable implementations
  • other operations (eg: stuff like Base64Binary.data(using:), FHIRPrimitiveProtocol.extensions(for:), Instant.asNSDate(), etc)
  • all of the asFHIR{Type}Primitive() extensions
• all initializers on FHIRType-derived classes
  • including the convenience initializers; since they typically default all of their parameters to nil, my understanding is that the compiler would end up emitting code only for setting those properties that actually are passed into the initializer, but i'll need to double-check that)
• all trivial operations on FHIRType and its derived classed (eg: the FHIRAbstractResource hash and equality operations)

there are some things that probably don't make sense to inline (ResourceProxy.get comes to mind; i'm not sure how the compiler would handle that)

[p2-apple]

That's a great suggestion. Have you done some investigation on which @inlineable attributes make a big difference? Some are obvious candidates, as you call out, but for others it would be good to have some data to see if the compiler actually ends up inlining them and what performance increase you get.

The side effect of @inlineable is that the framework will grow in size, and it's already quite large, so we should be very deliberate about this effort.

[lukaskollmer]

@p2-apple i did some very crude benchmarking at the time but nothing overly sophisticated; will take a closer look at this and report back

tbh i'm not overly worried about the size implications; the standard library already defines many of its operations as inlinable and it's totally fine overall (and i'd imagine that to have way more potential impact than the FHIRModels package ever could have). additionally, a function being inlinable only means that the compiler can inline it if it wants to; it doesn't have to do so. eg, if an app is compiled with -Osize, it'd likely skip a bunch of inlining in cases where it'd lead to unacceptable size increases