Chrome debug mode is Extremely slow

[anativ]

When chrome debugger is attached realm is extremely slow! makes it unusable for development
Happens both on IOS Simulator / Android Emulator

[dovfrank]

+1

[CodeTitanian]

+1

[alazier]

We know android is very slow. We have seen RPC roundtrip times on the order of ~40ms per operation which would slow things down to a halt for complex apps. Things on iOS should be up to a few orders of magnitude faster though.

[CodeTitanian]

It is extremely slow on iOS.
Basically it can't be used as development is not feasible.

[appden]

@CodeTitanian Are you seeing this on device or in the iOS simulator as well? Can you report what the response times look like for the rpc requests by looking at the Network tab in the Web Inspector? I see them averaging around 1ms.

[anativ]

It seems that every get_property takes ~4ms
The problem is that it seems that I have around ~3000 requests
How can I minimize the get_property requests?

[alazier]

A get_property is made every time you access a property value on one of the objects returned from the Realm apis. For Realm objects accessing any property would trigger this call. For List or Results objects, accessing the length property or accessing objects at a given index would trigger this. I suspect you are looping through a set of objects which could results in multiple get_property calls for each element in your collection.

Probably the best you can do to minimize these calls is to cache any information that is reused. Results.length would be an obvious choice here if you are looping through a results set - storing this in a variable could prevent a call being made for each element. If you are reusing object properties you could also try storing those in a var and reusing that. Another thing you could try doing is calling slice on a Results object and then using the returned JS Array rather than accessing the Results directly. This would essentially cache the length property and batch create objects at every index with the downside that the returned Array will not be updated when objects are changed or added.

Beyond that I'm not sure what else you can do easily. There are internal changes we could make to minimize some of these calls - we may be able to cache some property values internally and possibly even cache object properties or preemptively batch fetch some data. For the cases where performance issues are caused by looping through a set of objects these optimizations could possibly speed things up 2x-5x or more at the cost of added complexity. I'm not sure if this would be enough of a speedup to resolve the issues you guys are seeing.

The other alternative would be re-architect the way we do chrome debugging to do more work in js rather than forwarding all operations over rpc to the core Realm implementation. This would be considerable more work but may be necessary if the optimizations mentioned above are not sufficient. It isn't clear if this will be worth the effort as it seems that ReactNative will be moving away from chrome debugging to other alternatives.

[appden]

It's definitely significantly slower on Android simulators than iOS. I suspect the issue on Android may either be from overhead with the virtual machine networking stack or the passing everything through the JNI.

[krzkaczor]

There should be a note about this behaviour in the documentation. I was making research about using a different mobile database for next project in my company. I almost totally ditched realm react native because I was measuring performance by performance.now (which ofc requires debugger attached) and it was really bad.

[alazier]

@krzkaczor - we will definitely add this.

[cpsubrian]

Wish I had something more constructive to add here other than to say that performance in the chrome debugger is (at least in the short term) making it hard to adopt it.

For example: I have a scene that lists 50 U.S. states and a set of stats for each. This represents two 'queries': one to get all the states and another to get all the stats. The result sets are dumped into a redux store and are then connected to the scene component. The scene component implements a ListView that renders the states.

In the debugger loading the scene results in 6776 get_property requests for a total request time of around 40 seconds.

Without the debugger the scene takes around 500ms to fully render (using the scientific "One One-Thousand" measuring technique)

In the release build the scene loads basically instantaneously (probably around 50ms)

So, the 'real-life' performance of Realm has exceeded my expectations and the API hasn't been too hard to get use to, but the fact that my complex scenes are now virtually un-debuggable means I'm not sure I can stomach it even though it will deliver the best experience to the user.

I'm happy to provide whatever help or experience I can to improve this because the end-result would be a fast, stable db.

Note: I'm experimenting with replacing react-native-local-mongodb with realm. That library has worked fine for me but has much much slower insert times, somewhat slower reads, and I'm concerned about a lack of stability and support as compared to Realm.

[alazier]

Thanks @cpsubrian for the detailed use case. It's clear that chrome debugging performance is subpar and needs to be improved. The good news is that we should be able to speed things up considerably and just need to find the time to put the work in. I detailed some of the caching and batch-fetch optimizations we could make here #491 (comment) - will try to bump of the priority of working on this and will try to knock off some of the low hanging optimizations sooner rather than later. In the meantime if you want to have a crack at making some of these improvements 'm happy to help you get started.

[hbsndg]

how to solve the problems, many get_properties when I use Chrome Debug react native realm???

[jrwm]

Is it possible to turn off debugging only for Realm? It could be a workaround for this problem because I don't really need to debug Realm Network calls and things like that. ;)

[jrwm]

I wonder how anyone can possibly use Realm since Chrome debugging is essential for developing a React native app...

[ismdcf]

Any advancement in regard to this issue

[mlumbroso]

Any update on this? This is critical for me, as I've got a pretty complex app with multiple Schemas (i have more than 30000 requests to get_property, it's been 25 minutes and I can't even start the app to debug it properly...)

[nulleof]

I use chrome dev tools only for showing console.log() output. I've found that Mac OS console logging tool is working with Realm much more faster. Use $ react-native log-ios or $ react-native log-android in your terminal. https://facebook.github.io/react-native/docs/debugging.html#accessing-console-logs

[benoist]

I found that when keeping the chrome tab active and visible, the speed is normal. When the chrome tab is not active or hidden by an application running in the foreground it slows down.
The chrome tab has to be completely hidden, if an application is transparent its still normal speed.

[Arman92]

Any updates on this issue?

I have the same issue, debugging is really a pain, why does realm make so many rpc calls for get_property?
Does it call the get_property "Every Time" I access a prop of an object?

[invibot]

Any news on the issue?

[kristiandupont]

@invibot, sorry, not at this point. I will keep this issue updated when I make some progress.

[lodev09]

I'm using reactotron debugger for fast debugging. See their Tips & Tricks so you can ditch console.log to console.tron. Also, reactotron displays realm results properties nicely as well (good for inspecting data).

Hope this helps.

[nuvolarmobileteam]

Hi guys! I started a project using Realm as the database engine. When I faced the debugging issue sadly I had to move to another one. After v2.28.0 is it any better? Could anyone give some feedback?

Thanks in advance

[cheansiong]

I have use the 2.28.0, it has some improvement but still unbearable for my case.

[kneth]

@cheansiong For future work, it would be great if you can provide some context - for example how large is your data set?

[cheansiong]

@cheansiong For future work, it would be great if you can provide some context - for example how large is your data set?

@kneth
Sorry for that as I think my use case is pretty straight forward. Let me give some datas here.

It has two object type, eg: Setting, AppObject
Setting

• about 10 attributes storing server, user info, etc
• always only 1 object.

AppObject

• about 34 attributes storing combination of string and number, with id as primary key.
• has about 300 objects.

Notes:
Of course, the project has now grows to more object types now. And I have been using the Reactroton for log debugging.
The slowness is only experienced when "Debug JS Remotely" turned on.

Hopes this helps. :)

[nuvolarmobileteam]

Hey guys, just wanted to let you know that I wanted to give another try to Realm. Last time I tried I was using 2.6.x.

I installed 3.0.0-beta.1 and in my opinion the debugging experience is better. Right now the database has something like 1000 records across 6 different tables.

[cheansiong]

@nuvolarmobileteam

Yes, I agrees that it is significantly better. However, I think the performance is still not usable for scenarios where reading / writing about 200-300 objects at one point is required. My test scenario is each object has about 20-30 properties.

[nuvolarmobileteam]

@cheansiong In our case we are writing 500 objects at once and still performing good. It's also true that when we do so the db is empty, I don't know if that may affect.

[witalobenicio]

Version 2.28.0 is really far away from being usable for development. Sad!

[mattijsf]

I was experiencing slow debugging as well when starting to use realm-js with react-native. I was just using a single schema with 2 fields, empty db. Nevertheless, a simple transaction to a single object property froze the UI for 1 or 2 seconds. Without debugging the performance was great though. I was pretty must ready to give up on using realm-js because of this.

However, I was using the debugger from Visual Studio Code. When I switched to the Chrome debugger the performance was acceptable / good. It's not completely related to this issue but it might help people experiencing a similar issue when using Visual Studio Code's debugger.

• Realm JS SDK Version: 2.29.2
• Node / React Native: 10.16.3 / 0.60.4
• Client OS & Version: iPhone SE / iOS 12.1 simulator

[nuvolarmobileteam]

That is a nice tip @mattijsf . Thanks for sharing!

[cyqui]

Decided to give a try to realm with react native as it looked like it could help our offline storage to become more maintainable and "jimmy proof" rather than our custom file namming.

The use case is : storing timeseries (datetime + up to three value) shown to the user for each day for 3 variables at the same time.
Showing only two years at a time (for deltas). And the result is that i can't display the year screen in debug anymore. It is fine with a release build.
So the data volume is about "365 * 2 (years) * 3 (variables)" entries.

I really liked the way realm integrates with react native (migrations, schema, queries etc..) but that's definitely a blocker for us.

[trickeyd]

Wow - after a long thread, this comes to an abrupt stop at the end of 2019. Was there some resolution?

After some research (tho sadly not seeing these threads) I replaced large chunks of my app's redux-persist with realm due to the many hundreds of items I'm sifting through.

The promise of realm is great, but my debugger implodes when I first write all the objects.

I am on the latest version, so I wonder why this conversation has ceased...

(I see the merge above, but I've been reading for over two hours now, and it is way past my bedtime, so may have to check that out tomorrow)

[kneth]

@trickeyd We believe that migrating to Hermes will give our users a better debugging experience (using Flipper). So you can say that we have stopped enhancing the Chrome debugger.

For Hermes and Flipper, please take a look at #3940

[kneth]

The support of the Chrome debugger was removed in version 11.0.0 and we ask you to use Hermes and Flipper.