Initialisation/Migration Performance - What does good look like?

[dlbuckley]

Overview

We are currently doing an investigation in to our app startup times and are looking to improve them where we can. We have added some logging in and around this area and have noted that the realm migration/initialisation is taking quite a significant amount (80-90%) of that time (anywhere from 0.4-4 seconds for the 90th percentile & 0.25-3.2 seconds for the 50th percentile).

I've been looking around to see how our results compare to others out in the wild and I've not found much in the way of data to compare to. I've also looked around for strategies to improve initialisation/migration performance and again can't find much out there.

What I'm looking for is either some strategies to improve initialisation/migration performance (or just the performance of realm in general) and any metrics as to what 'good' looks like.

Implementation Details

Our migration currently has 18 migration steps which are locked behind version checks e.g:

let realmMigration: MigrationBlock = { m, oldVersion in
    if oldVersion <= 70700 {
        // Do stuff here
    }
    // ...
}

let config = Realm.Configuration(
    fileURL: containerURL,
    schemaVersion: schemaVersion,
    migrationBlock: realmMigration
)
Realm.Configuration.defaultConfiguration = config

do {
    _ = try Realm()
} catch {
    // Recovery
}

*This is greatly simplified but encapsulates the general process

For most users most of the time these migration steps are no-op. We release once per week which could be a contributing factor, but most of the time we don't add any more migration steps. This could then be linked to initialisation, but I'm not sure what the contributing factors could be here without checking out realm and profiling it. Finally, our realm size on disk is typically <50mb on the high end, but normally much smaller.

I'm hoping someone with a bit more knowledge around realm (I've only been using it for a few weeks after starting a new job) can help, or at least point me in to the right direction towards some docs/articles. I don't mind if the suggestions are for far reaching changes like splitting up in to multiple realms (if that is even a recommendation), at least I know what I will be dealing with.

EDIT: For reference anything over 400ms to render the first frame is on the slow side in Apples eyes so anything we can do would be great.

[dlbuckley]

Since the engagement on this topic has been 'light' I thought I would post some of my findings and the exploration avenues I've taken over the past few days;

Testing

I've taken the approach of simply poking Realm with different scenarios to see how it reacts and measuring the time to initialise. I wanted to understand the cost of the 'magic' behind realm so we can take a more educated approach to optimising the start times, or at least know where to start looking. Lets start with some base measurements:

Creating an empty project, importing Realm with SPM and simply calling Realm() with the setup similar configuration to the post above and no existing database takes ~0.015 seconds on an M1 Pro in the iOS 16.2 simulator (averaged over 5 runs).

For reference running our app on the same setup in the simulator results in a Realm init time of ~0.75 seconds.

Model Structures

• Including 1 model with 4 properties (String, Int, Bool, Date) + a primary key (ObjectId)
  • ~0.025 seconds (average over 5 runs)
  • Increase of ~0.01 seconds
• Including 1 model with 1000 properties (all String values) + a primary key (ObjectId)
  • ~0.114 seconds (average over 5 runs)
  • Increase of ~0.099 seconds
• Including 1 model with 1000 properties (all Int values) + a primary key (ObjectId)
  • ~0.065 seconds (average over 5 runs)
  • Increase of ~0.050 seconds
• Including 27 models with varying numbers of properties, some with List and relationship properties + a primary key (ObjectId)
  • ~0.037 seconds (average over 5 runs)
  • Increase of ~0.022 seconds
• Including 100 models with 1 property (String) + a primary key (ObjectId)
  • ~0.056 seconds (average over 5 runs)
  • Increase of ~0.041 seconds
• Including 100 models defined in a separate framework with 1 property (String) + a primary key (ObjectId)
  • ~0.057 seconds (average over 5 runs)
  • Increase of ~0.042 seconds
• Including 100 models defined within the app target and 100 models defined within a framework with 1 property (String) + a primary key (ObjectId)
  • ~0.067 seconds (average over 5 runs)
  • Increase of ~0.052 seconds

Database Size

• 5.2MB file populated with a single model x 100 (1000 string properties each with a random UUID)
  • ~0.135 seconds (average over 5 runs)
  • Increase of ~0.120 seconds
• 47.8MB file populated with a single model x 1,000 (1000 string properties each with a random UUID)
  • ~0.135 seconds (average over 5 runs)
  • Increase of ~0.120 seconds
• 5.5GB file populated with a single model x 100,000 (1000 string properties each with a random UUID)
  • ~0.135 seconds (average over 5 runs)
  • Increase of ~0.120 seconds
• 9.98GB file populated with a single model x 200,000 (1000 string properties each with a random UUID)
  • ~0.135 seconds (average over 5 runs)
  • Increase of ~0.120 seconds
• 58.9MB file populated with 27 different models with varying number of properties (between 3 and 10), some with List and relationship properties (using the same models from the 4th scenario in the model structure tests) with a. random number of models between 1,000-10,000
  • ~0.072 seconds (average over 5 runs)
  • Increase of ~0.057 seconds

Brief Analysis

There are several interesting findings we can take from the results above:

• Database size doesn't have a dramatic impact on the time to init, it's more to do with the model structure
• Models residing in other frameworks don't contribute much, if anything, to the init time.
• The number of different model types has a significant impact on init time
• The more properties a model has the bigger the impact on init time
• Model property types can have a big impact
• The last database size test most represents a real world scenario (although simpler than our actual app implementation), and if we were to multiply the increase in time to match the number of models we have in our app (254) that alone contributes to a 0.54 seconds increase. This goes a long way to explain why we are seeing slow init times.

Conclusion

There is a lot of 'magic' going on when initialising an instance of Realm, and a lot of it is opaque. We have found that as our use of Realm has grown (currently 254 models of varying complexity) it's contribution to the slow down of app launch has dramatically increased (note the times we are seeing reported from the app in the original post).

When I started this journey I was looking for ways to optimise our use of Realm to speed up app launch times, but with these findings it's looking like we only have two viable options:

• Defer Realm initialisation until later in the app lifecycle so we can have more control over what the user is experiencing while Realm does it's 'thing'.
• Look to replace Realm with another solution; if our persistence model continues to grow, Realm's contribution to the app launch time will continue to grow.

Next Steps

Maybe we can be hopeful and find that there is a bug contributing to an increase in Realm init times. I'm going to raise an issue and link back to this discussion in the hope that this analysis can be helpful. If there is a bug and we can get a quick win from fixing it within Realm itself then that benefits everyone, but I have a feeling this is due to the 'magic' that realm tries to do for us up front.

If everything is working as expected then we will need to start exploring the alternate options mentioned above, or maybe there is something I've not yet considered so any suggestions would be great. But from our point of view the amount of time Realm is contributing to app startup times for our users is becoming a problem, especially for users on older/slower devices, so doing nothing, at least for us, isn't an option.

Thanks for reading, I hope this was useful for someone!

[tgoyne]

Our benchmark for Realm init uses the schema for our test suite with ~400 classes and a total of ~6000 properties and on a iPhone Xs (4 generations old but far from a total potato) schema init takes ~100ms, creating a new Realm file takes 10ms, and then reopening an existing file (with no data, but we generally don't touch any of the actual data while opening) takes 5ms. This isn't wildly different from the numbers you're seeing, but it is faster. Can you maybe share some of the model definitions you're testing with? There's a few performance traps related to them (e.g. @Persisted var list = List<Int>() is meaningfully slower than @Persisted var list: List<Int>) and maybe you're hitting one of them?

Migrations are not run at all unless you change the schema version in the config. A no-op migration does have a bit of overhead, so if you're doing something like bumping the schema version with every release even if the schema hasn't changed then you may want to avoid doing that. When a migration does run most of the time spent is usually going to be in whatever you write in your migration block; obviously if you loop over all of the objects in your Realm and transform them, that can take a while if you have a lot of data. The schema changes which have significant potential to be slow even without you writing something in the migration block that does a lot of work are changing a property from non-optional to optional and adding an index to an existing property.

If you do have slow migrations and don't want to have a slow startup even when the migration happens, I think there inherently isn't really any solution other than deferring the point in app startup where you need to read from the realm. You can use Realm.asyncOpen() to perform the migration on a background thread rather than blocking the main thread, but that's only helpful if you can defer needing the Realm.

Enabling compact on launch can obviously have a significant effect on your startup time, but you appear to not be using that.

[tgoyne]

Anywhere that you're doing @Persisted var field = T() should generally be @Persisted var field: T. Assigning a literal (e.g. = 0) is fine. Assigning a non-literal default value that isn't the type's default init will have some performance impact, but is probably not worth caring about; it's not an unneccesary perf hit, and this is the sort of thing that starts to matter when you do it 500 times but not when you do it 5 times.

Both schema initialization and general read performance rely on init() being reasonably fast. Swift's reflection functionality currently requires an object instance†, so a nontrivial part of the runtime of schema init is just instantiating an object of each Object subclass defined. The performance gotcha with default values is that the default value is always constructed every time an object is instantiated even if it's never going to be used, while if instead you give no default value we'll construct a T()†† on first access instead. This doesn't make a difference for property types like Int where constructing the value is free, but = List() (or any of the other collection types) makes a few memory allocations, and = UUID() generates a UUID, which is a fairly expensive thing to do.

† There's some exciting upcoming functionality around macros and custom reflection metadata that I'm hoping will let us push a lot of the schema initialization work that we currently do at runtime to compile time instead.
†† Except for Persisted<ObjectId>, where we default to ObjectId.generate() because ObjectId() returns an all-zero objectid, unlike UUID() which generates a new UUID.

[dlbuckley]

Sorry for taking a little longer to come back to you @tgoyne.

Thanks for spending some time giving more of an insight into what Realm is doing internally to understand and build out the schema. I now understand why things are done how they are and why your suggestions could help with the init performance journey.

Over the past few days I've been converting over our models to use the @Persisted property wrapper (we hadn't converted anything up until now and were still using @objc dynamic) and removing the default initialisation of non-primitives from the properties. Before the conversion we were seeing init times of ~668ms, and now since the conversion we are seeing a decrease in init times to ~582ms. This marks a noticeable improvement but not quite as much as I had hoped and still quite a bit more than your numbers.

Note: These numbers were taken on an iOS 16.2 simulator.

I can't share the models bit I can share some stats:

Number of Models: 254
Number of @Persisted properties: 2153

I think I need to start having a look at things in Instruments to see where there are any more time improvements to be had unless there are any other suggestions/gotchas which I should be looking out for.

[rjchatfield]

@tgoyne Any updates on...

† There's some exciting upcoming functionality around macros and custom reflection metadata that I'm hoping will let us push a lot of the schema initialization work that we currently do at runtime to compile time instead.

:excited:

[jacobsapps]

I'd love an update on this, we've noticed the Realm schema initialisation is a serious launch-time bottleneck

† There's some exciting upcoming functionality around macros and custom reflection metadata that I'm hoping will let us push a lot of the schema initialization work that we currently do at runtime to compile time instead.

[tgoyne]

You can check out rjchatfield's work on using macros to do a lot of the schema discovery work at compile time at https://github.com/rjchatfield/realm-swift-macro.