Very slow performance on debug mode

[Mairramer]

Is there an existing issue?

• I have searched existing issues

Build info

• objectbox version: 4.3.0
• Flutter/Dart version: 3.29.3
• Build OS: macOS 15.4.1 (24E263)
• Deployment OS or device: Android 14,Android 15, iOS 18.4

I'm migrating from Isar to ObjectBox and facing a major issue in debug mode. I’ve done some investigation but haven’t identified the root cause yet.

I’m already using ObjectBox in another app (Flutter version 3.24.5) without any performance issues during debugging. However, in this other (much larger) app, I’m unable to run it smoothly in debug mode. After some research, I found two possible reasons:

1. Merged platform and UI threads – Flutter issue #150525. This specific comment caught my attention.

2. Hot reload performance degradation when using multiple isolates – Flutter issue #169437

I’ve tried using the following flag:

<meta-data
    android:name="io.flutter.embedding.android.DisableMergedPlatformUIThread"
    android:value="true" />

But the result was the same.

My question is: is this a Dart/Flutter limitation, or is it truly related to the merged thread behavior and FFI communication?

It's also worth noting that I don’t experience this problem with Isar, even though it also relies on FFI.

[Mairramer]

My app follows an offline-first approach, so on the home screen it performs (or attempts to perform) two separate synchronization processes.
Each of these triggers its own isolate via ObjectBox, which leads to noticeable performance degradation.

[greenrobot-team]

Thanks for reporting and making us aware of the merged threads change. At this time I don't fully understand if this might have an impact when using ObjectBox APIs, so we will have to look into this when there is time.

However, the merged threads change is only enabled since Flutter SDK 3.32. Yet, you wrote you are using Flutter SDK 3.29?

In that case what exactly do you mean by "unable to run it smoothly in debug mode"? You should be able to tell if performance degrades after doing a hot reload or at some other point?

[Mairramer]

However, the merged threads change is only enabled since Flutter SDK 3.32. Yet, you wrote you are using Flutter SDK 3.29?

Actually, thread merging was introduced in version 3.29 but only became the default in version 3.32.

In that case what exactly do you mean by "unable to run it smoothly in debug mode"? You should be able to tell if performance degrades after doing a hot reload or at some other point?

After migrating to ObjectBox, hot reload performance became noticeably slower. My app runs two queries during startup and performs additional queries only on user demand. I’m not sure if the slowdown is related to the overall size of the app, but it shouldn’t be, considering the amount of data is relatively small compared to another project I’m working on, which also uses ObjectBox with Flutter (version 3.24) and doesn’t suffer from this issue—even though that project has periods of much heavier query usage.

[greenrobot]

Most queries should perform in a few milliseconds (or sub-milliseconds) - if they have a proper index. Maybe you can pinpoint the slowdown, e.g. by performance logging (measure the duration of some action and log it) to give us a clearer picture.

[Mairramer]

@greenrobot As I mentioned, the app runs two queries during startup:

For the first one, I’m using the query builder:

 Query<T>? query;
    try {
      query = store.box<T>().query(condition).build();
      if (limit != null && limit > 0) {
        query.limit = limit;
      }
      return query.find();
    } catch (e) {
      throw const PersistenceException();
    } finally {
      query?.close();
    }

Execution time

[log] Start find Punch - 2025-06-17T09:42:32.360172 - Status: PunchLocalStatus.synchronized - Limit: none
[log] End find Punch - 2025-06-17T09:42:32.366161 - Execution time: 5 ms

For the second one, I’m simply using getAllAsync:

 try {
      return store.box<T>().getAllAsync();
    } catch (e) {
      throw const PersistenceException();
    }

Execution time

[log] Start find Activity - 2025-06-17T09:42:33.402156
[log] End find Activity - 2025-06-17T09:42:40.110498
[log] Activity query execution time: 6708 ms

The issue itself seems to be with getAllAsync(). I'll refactor the code to see what the performance impact is.

[greenrobot]

The issue itself seems to be with getAllAsync()

@Mairramer How many objects do you have?

[Mairramer]

The issue itself seems to be with getAllAsync()

@Mairramer How many objects do you have?

It is empty.

[greenrobot]

please double check that - it would be extremely surprising for a store.box<T>().getAllAsync() without any object to take more than a few milliseconds. There's no way this takes 6 seconds - maybe something else is interfering or you are measuring not just "get all".

[Mairramer]

please double check that - it would be extremely surprising for a store.box<T>().getAllAsync() without any object to take more than a few milliseconds. There's no way this takes 6 seconds - maybe something else is interfering or you are measuring not just "get all".

Could the AppFileModel relationship be causing interference?

@Backlink('activity')
final ToMany<AppFileModel> appFiles = ToMany();

@Entity()
class AppFileModel {
  @Id()
  int? id;
  final String? name;
  final String? extensionName;
  final String? path;
  final String? base64;

  @Property(type: PropertyType.byteVector)
  final List<int>? bytes;
}

[greenrobot]

If there really are no objects, relations will not matter.

It'd be helpful if you could actually pinpoint the issue. How do you know it is related to ObjectBox? We'd need some hard data to continue.

[Mairramer]

If I simply comment out the getAllAsync() call and return an empty list, there are no freezes and hot reload becomes significantly faster. The issue might be related to this: flutter/flutter#169437.
It’s probably caused by this relationship, since getAllAsync() will open a separate isolate.

I'm also a little surprised, I've used isolates in other contexts but this is the first time I've seen this problem.

[Mairramer]

I could switch to using store.box<T>().getAll() instead, considering that this store is not expected to hold a large amount of data. Based on user metrics and usage frequency, the data volume should remain low, even though this feature is core for some customers.

[greenrobot]

I could switch to using store.box().getAll() instead

I just wanted to suggest the same... 🙂 Performance wise this should be fine for a couple thousand objects (milliseconds).