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 https://github.com/realm/realm-js/issues/491#issuecomment-226243882 - 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.

[martsie]

From what I've seen of reactotron there is no support for stepping through code or seeing the backtrace for exceptions (is that correct?).

Is the issue that realm calls get pumped through the network panel just for the purposes of debugging? I have a list of 3000 objects which loads instantly with debugger off and takes 1-2 minutes with debugger on.

If so, could somebody point me in the direction of where these realm falls get passed into the network panel for debugging? I've had a look but I'm having a hard time understanding the flow. Happy to help with a pull request to move the extra debugging information underneath a global flag on realm so we can choose to disable the network request debugging to speed up development. Waiting 1-2 minutes to load my app whenever I make a change and need to debug is making it challenging to get any work done - but realm is so awesomely fast when not in debug mode!

[lodev09]

@martsie yes I think they don't have that feature yet. As for me, I can live with it by just inspecting data and doing some log traces until they fix this issue.

[Arman92]

Can't believe this issue is not fixed by now!

[lodev09]

It's open source, you can't complain.

[martsie]

In general I'd agree however it's open source tied to a PAAS that has a $1500/month plan (as well as a very generous free plan). Because of this bug the product virtually unusable for professional React Native development where you may need more advanced debugging than just logging data.

[lodev09]

I'd better contact their support directly if I'm subscribed to that plan rather than complaining publicly - I might get direct answer from dev :)

[martsie]

With this thread open developers can quickly find out why their debugging is so slow and abandon realm if they need to. Follow up frustration messages keep the topic alive and allow people to see that it's still a current issue even if it's being ignored by developers.

Unfortunately this seems like a really hard bug to fix. I had a good look into how this is being done and there didn't seem to be any clean solutions that I could send a pull request in for.

[lodev09]

I guess you're right but I'm pretty sure they have their reasons why they haven't fixed this yet. complaining doesn't really help :(

[cpsubrian]

Pretty sure realm wants to know if they are losing customers over a developer pain point. They lost me over this one :man_shrugging:

[invibot]

and me 😕

[fidelisrafael]

Hi guys, I'm working in a project with realm and it's getting REALLY hard to debug things, for now we're looking for options without replacing Realm, which is very good and fast...but software development it's not only about perfomance, it's too muh related with humans...and humans need to do very deep debugging to get closer to solve things and Realm is not helping at all in this sense...

I want to know if theres some plan or something that you guys are doing about this. I want to help if possible, I think that this is VERY important to all companies relying in Realm, if we can't debug, we can't scale and deliver our product.

Thanks in advice and I really appreciate the work done in Realm!

[benoist]

I've since migrated away from realm. Not because I can't debug realm but because it stopped me from debugging the rest of my application as well

[lodev09]

It's not the end of the world guys, there are alternatives to chrome debugging like reactotron or even console.warn(). For me, I'd always go for performance with little debugging pain.

It's not like you can't run your app without debugging every line of your code :)

[fidelisrafael]

I understand your point @lodev09, but real debugging and only logging are different things, I can't debug my application every time with Reactotron and only console.log(), I need breakpoints... With reactotron and console.log I will waste TOO much time debugging(logging), and as @benoist it's not a problem with Realm not being "debugable", the real problem is that Realm don't let me debug my application...Right now I'm having a problem and I can even start the Chrome Debugging(or VSCode debugging for react-native) cuz when app launches and Remote JS Debug is enabled Realm dont allow debugging...

[lodev09]

Well I guess I'm not in the point of needing to do breakpoints. So yeah, since I want performance, then I'll have to live with it. If they fix it, great, and if they don't, then I have no choice - there's always a downside :(

[kristiandupont]

We are not ignoring this, we are painfully aware of the severity. I really hope and expect that we will be able to prioritize this very soon.

[jcharlet]

totally agree with @fidelisrafael. @kristiandupont you should maybe warn users in your documentation that debugging in chrome is currently very unstable. I'm giving it an extra day or two to try to fix my debugging issues with realm, but if I have to sacrifice debugging vs realm, at this point, it's much simpler for me to go for another db.

[martsie]

Ah ... the new project I joined chose to adopt Realm and now I'm sitting here again with 5-minute app startup times all over again. It would be really great to fix this soon.

Does anybody have some alternatives to Realm that they've switched to? I can find some time to write a bridging adapter that will allow developers to continue to use the Realm calls but with a different back-end that doesn't make debugging impossible.

[martsie]

Does anybody have an idea of whether it would be possible to do the following:

Incorporate the Cocoa and Android version of Realm into a react-native plugin then instead of using realm-js you could use something like 'realm-react-native' which would then send every request using the react native bridge, and then the RPC would happen on the device instead of through the debugger?

It wouldn't be super fast but it could be a lot better than what we have now.

[sheshavpd]

I'm loving realm for its fastness. But it's very hard to compromise for 5+ minutes to debug the app, since react native needs debugging in the first place. I'm having no options but to move away from realm 😞

[fidelisrafael]

Hey Realm maintainers, how we can help to solve this? We can create a topic to discuss the possible ideias to solve? Or maybe here? Can you guys help us with some directions? (Maybe some links where we maybe fix the code or something like this).

Are you guys really looking at this? RIght now my application is still using Realm(it's amazing!), but this will be a real problem in a few months when our team grows up. Let's try to look a this which is one of the major problems(for me the unique "real") of Realm today...

[jrwm]

Just leave Realm. It's dead project.

[bmunkholm]

@jrwm Sad to hear that's your impression :-( That is however not the case. We have tons of good feature requests and limited resources. So it's really great to hear that some devs (e.g. @fidelisrafael ) are willing to step up and help us out! We should definitely list up some of the ideas for how to improve this. We will get back asap on that.

[jcharlet]

Rafael, Brian, great to hear! looking forward :)!

[bmunkholm]

@alazier actually made some suggestions way back: https://github.com/realm/realm-js/issues/491#issuecomment-226243882. @fidelisrafael what else would you need to get started?

[martsie]

Alazier's suggestion didn't mention using ReactNative bridge instead of setting up an RPC server on the device.

I made a bit of progress setting it up through React Native bridge and I think it's a pretty maintainable solution but I don't know about performance just yet. If using the ReactNative bridge ends up being performant I think it'll be the most 'correct' solution as Realm will be running native on the device and its javascript library will be pushing and pulling data from it (which is how RN libraries generally work).

[fidelisrafael]

@bmunkholm Thank you for your followup! As @martsie said, I'm using Realm with React Native too and I even cant reach the step where the requests are made...For what I remember for this step: Looks like Realm theres a HTTP/RPC server embeded, right? When I launch my application I was getting the error described in #284. I did the adb forward tcp:8082 tcp:8082 trick but this worked just for a few times... For me the main problem is not being slow, most of time it's just not letting me launch my application in development (I tried in Ubuntu 14.04, and o Mac OS Sierra...the adb trick worked better in Mac OS.

@martsie If this allow users to debug better while this problem is not solved, can be at least one recommendation in documentation, I think.