I have a function a implemented in a protocol extension that's called millions of times per second. It in turn calls a function b which is required by the protocol which does not have an implementation in the extension. According to the Time Profiler in Instruments, function a spends a lot of time in __swift_instantiateGenericMetadata. I get a big performance bump by moving a out of the extension and re-implementing it identically in each type that conforms to the protocol. Is there any way to get the compiler to do this itself? Do I need to write a macro to do it for me? There are screenshots from Instruments illustrating the issue below. Thanks! These traces are made a tiny bit more confusing because the real names of a and b are the same: read(at:). (They take different types as their parameters.) Here's the Time Profiler trace of the protocol extension implementation: And here's the trace for the duplicated-in-each-type version:

There was a section in the talk about how we can break down migration into smaller changes, and that we have an opportunity to run app-specific code in between migration steps. However the talk didn't touch on how can can achieve this, besides a single sentence, which doesn't give enough detail at least for me to figure out how to do it. Intuitively, an event loop could be built that opens the persistent store with the lightweight migration options set and iteratively steps through each unprocessed model in a serial order, and Core Data will migrate the store. Given the automatic nature of the lightweight migrations, especially in the case where we're using NSPersistentCoordinator, doesn't the automatic system just zoom through all of the migrations from model A --> A' --> A'' -> B? How to we make it stop so we can execute our own app code? Thanks!