Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chrome debug mode is Extremely slow #491

Open
anativ opened this issue Jun 14, 2016 · 171 comments
Open

Chrome debug mode is Extremely slow #491

anativ opened this issue Jun 14, 2016 · 171 comments

Comments

@anativ
Copy link

@anativ anativ commented Jun 14, 2016

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

@dovfrank
Copy link

@dovfrank dovfrank commented Jun 14, 2016

+1

1 similar comment
@CodeTitanian
Copy link

@CodeTitanian CodeTitanian commented Jun 14, 2016

+1

@alazier
Copy link
Contributor

@alazier alazier commented Jun 15, 2016

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
Copy link

@CodeTitanian CodeTitanian commented Jun 15, 2016

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

@appden
Copy link
Contributor

@appden appden commented Jun 15, 2016

@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.

screen shot 2016-06-15 at 1 20 54 am

@anativ
Copy link
Author

@anativ anativ commented Jun 15, 2016

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?

screen shot 2016-06-15 at 6 36 33 pm

@alazier
Copy link
Contributor

@alazier alazier commented Jun 15, 2016

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
Copy link
Contributor

@appden appden commented Jun 29, 2016

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
Copy link

@krzkaczor krzkaczor commented Jul 6, 2016

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
Copy link
Contributor

@alazier alazier commented Jul 9, 2016

@krzkaczor - we will definitely add this.

@cpsubrian
Copy link

@cpsubrian cpsubrian commented Jul 21, 2016

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
Copy link
Contributor

@alazier alazier commented Jul 22, 2016

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
Copy link

@hbsndg hbsndg commented Aug 4, 2016

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

@jrwm
Copy link

@jrwm jrwm commented Aug 17, 2016

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
Copy link

@jrwm jrwm commented Aug 18, 2016

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

@ismdcf
Copy link

@ismdcf ismdcf commented Aug 23, 2016

Any advancement in regard to this issue

@mlumbroso
Copy link

@mlumbroso mlumbroso commented Aug 31, 2016

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
Copy link

@nulleof nulleof commented Sep 10, 2016

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
Copy link

@benoist benoist commented Oct 18, 2016

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
Copy link

@Arman92 Arman92 commented Dec 6, 2016

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
Copy link

@invibot invibot commented Jan 5, 2017

Any news on the issue?

@kristiandupont
Copy link
Contributor

@kristiandupont kristiandupont commented Jan 5, 2017

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

@lodev09
Copy link

@lodev09 lodev09 commented Feb 16, 2017

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.

@geriux
Copy link

@geriux geriux commented Apr 25, 2019

Like everyone else, implemented it, really liked how it works until it is time to debug. Definitely a big let down so we'll be moving pass realmjs for now.

@gsklee
Copy link

@gsklee gsklee commented May 9, 2019

@tgoyne @kneth Hey folks, any words on this? My team is also doing spikes on moving away from Realm.js right now simply because the debugging story is totally broken (we've been using it for 2 years straight but finally decided we're fed up) but I feel like it might be great to ping you guys and see if there's still any hope on this issue.

@csotiriou
Copy link

@csotiriou csotiriou commented May 9, 2019

@gsklee @agurtovoy Your best bet is to use Safari debugger.

To add to @agurtovoy 's comments: The comment he linked mentions that you won't have source map support. You can overcome even that. Just follow the linked comment, and use Haul as your bundler. You will have much better debugging experience than even with the original chrome.

Other than that, the only hope is for realm to refactor the code to take advantage of the new JSI which is suitable for these purposes. Now that Mongo has bought Realm, I don't quite know if and when this issue will be fixed 100%.

@tgoyne
Copy link
Member

@tgoyne tgoyne commented May 9, 2019

The JSI stuff doesn't have any relevance to this as the slowness isn't due to how we interact with react native. You'd see the same poor performance if you used the browser implementation of the Realm API in a normal webapp with no React involved at all. Making a HTTP request for every property read just inherently can't perform well and making big gains requires coming up with a less chatty protocol.

@csotiriou
Copy link

@csotiriou csotiriou commented May 9, 2019

@tgoyne thank you for the clarification, but I just re-read the comment in #491 (comment) .

According to the information I have read here, a get-property call is being made as an RPC call. Realm is not developed as a proper React Native module from the ground up, and that is what causes the need for RPC calls. If Realm was developed as a React Native module, it would lose it's edge, since Realm is Synchronous, and React Native modules force it to be asynchronous.

However:

This is exactly the reason why the React Native team is rearchitecting React Native. JSI and TurboModules will allow NATIVE code to be executed synchronously and provide results on the JS side. Not only that, but there will be shared memory across the Native and JS side. Which is exactly what Realm needs to become a proper React Native module from the start without losing its edge, isn't it?.

I'm sorry if I have misunderstood the points made by both members of Realm and React Native, but it seems to me like React Native is moving fast towards providing interfaces like the ones Realm needs.

https://medium.com/@christian.falch/https-medium-com-christian-falch-react-native-jsi-challenge-1201a69c8fbf

@tgoyne
Copy link
Member

@tgoyne tgoyne commented May 9, 2019

When using chrome debugging, your app's javascript is actually running in a normal web app in a chrome tab, rather than in a javascript context running in your mobile app. You can't load native modules when running in Chrome, so React Native turns these into RPC calls over a websocket to the code running in the mobile app. Since we don't go through the react native native module API we have to implement a similar RPC mechanism ourselves, but it's not fundamentally different from what ends up happening for a normal RN native module.

The reason why this is such a big performance problem for us and not for anyone else mostly comes down to API design. With a proper RN-style async API, you'd normally make a handful of native calls when updating your state and zero in your render function. Tacking on a few ms to each of those calls is completely unnoticeable. Realm, OTOH, is designed around making lots and lots and lots of native calls. When native calls are cheap this performs very well; when you add even 1ms delay onto each native call it performs terribly (and it's often quite a bit more than 1ms).

The TurboModules/JSI work is sort of orthogonal to all of this. It theoretically might be possible to reimplement Realm on top of it as a proper RN module and that'd let us delete all of our chrome debugger-related code, but that wouldn't inherently make our chrome debugger performance problems go away. It wouldn't change the fact that the Realm native library and the JS code being debugged are running in separate JS engines that have to communicate too frequently.

@tgoyne
Copy link
Member

@tgoyne tgoyne commented May 16, 2019

#2373 brings some improvements here. It adds a caching layer which for Rocket.Chat has a ~95% hit rate on property reads and makes the app at least somewhat usable in chrome debugging mode. It's still not a great experience, but I'd be interested in feedback on if it does enough that further incremental improvements would be worthwhile, or if it's still not in the range where trying to use it is actually productive.

@gsklee
Copy link

@gsklee gsklee commented May 17, 2019

Exciting news @tgoyne, really appreciate the effort! 😸

Some update from my part:
Our team is experimenting with a new debugging setup with Reactotron as the new primary debugger. It doesn't offer a component inspector or the ability to step through breakpoints, so we still need to keep React Native Debugger handy, though at the same time it brings some new and powerful benefits such as saga debugging and custom commands. Our hope is that Reactotron will be able to cover up to at least 80% of our daily debugging needs so we won't need to deal with the crappy debugging experience that often.

@kesha-antonov
Copy link

@kesha-antonov kesha-antonov commented May 17, 2019

I thought of adding Realm to my app but after seeing this issue I'm in doubt.
Does anybody solved it?

@kneth
Copy link
Member

@kneth kneth commented May 22, 2019

We have released v2.28.0 which contains #2373. Not that it will take away all the pain of debugging, but we hope that you will find the improvements useful.

@nuvolarmobileteam
Copy link

@nuvolarmobileteam nuvolarmobileteam commented Jun 17, 2019

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
Copy link

@cheansiong cheansiong commented Jun 17, 2019

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

@kneth
Copy link
Member

@kneth kneth commented Jun 27, 2019

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

@cheansiong
Copy link

@cheansiong cheansiong commented Jun 27, 2019

@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
Copy link

@nuvolarmobileteam nuvolarmobileteam commented Jun 28, 2019

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
Copy link

@cheansiong cheansiong commented Jul 3, 2019

@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
Copy link

@nuvolarmobileteam nuvolarmobileteam commented Jul 3, 2019

@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
Copy link

@witalobenicio witalobenicio commented Jul 4, 2019

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

@mattijsf
Copy link

@mattijsf mattijsf commented Aug 24, 2019

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
Copy link

@nuvolarmobileteam nuvolarmobileteam commented Aug 26, 2019

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

@cyqui
Copy link

@cyqui cyqui commented Sep 16, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet