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 · 134 comments

Comments

Projects
None yet
@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

This comment has been minimized.

dovfrank commented Jun 14, 2016

+1

1 similar comment
@CodeTitanian

This comment has been minimized.

CodeTitanian commented Jun 14, 2016

+1

@alazier

This comment has been minimized.

Contributor

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

This comment has been minimized.

CodeTitanian commented Jun 15, 2016

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

@appden

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

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

This comment has been minimized.

Contributor

alazier commented Jul 9, 2016

@krzkaczor - we will definitely add this.

@cpsubrian

This comment has been minimized.

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

hbsndg commented Aug 4, 2016

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

@jrwm

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

ismdcf commented Aug 23, 2016

Any advancement in regard to this issue

@mlumbroso

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

invibot commented Jan 5, 2017

Any news on the issue?

@kristiandupont

This comment has been minimized.

Contributor

kristiandupont commented Jan 5, 2017

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

@lodev09

This comment has been minimized.

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.

@nielsmadan

This comment has been minimized.

nielsmadan commented Sep 30, 2018

I was referring to the detailed explanation where it says:

In React Native the JavaScript context runs on a separate worker thread and cannot be directly accessed from native code - instead React Native provides a "bridge" that allows native code and JavaScript code to talk to each other by asynchronous JSON messages. Realm circumvents this by using private React Native APIs to gain access to the JavaScript context and make its APIs available directly in the JavaScript worker thread, rather than via the React Native Bridge.

@cmelchior

This comment has been minimized.

Contributor

cmelchior commented Oct 1, 2018

@Eyesonly88

This comment has been minimized.

Eyesonly88 commented Oct 2, 2018

To add to @agurtovoy awesome steps, you can make Safari automatically open the new JSContext when you manually reload (CMD+R) the app or Live Reload by selecting the Automatically Show Web Inspector for JSContexts:

image

@csotiriou

This comment has been minimized.

csotiriou commented Oct 21, 2018

I can confirm that switching to Haul solved this for me. I now use safari for debugging, and I can even inspect Realm objects properly.

Switching to Haul for the time being seems to be the only thing that works right now.

https://github.com/callstack/haul

@guptaamol

This comment has been minimized.

guptaamol commented Oct 27, 2018

Hey hi, i was just looking around this thread. The console.log statement works good enough for me but makes it really painful to inspect elements. It would be really helpful if we could disable realm debugger in some way and things could just work.

Thanks.

@philjoseph

This comment has been minimized.

philjoseph commented Oct 29, 2018

I just read the warning in the README.cmd https://github.com/realm/realm-js#issues-with-debugging it is an understatement. Not "some users" but all users that tried to debug and not "being too slow" but unusable. We shall be fair with the community

@jfbaraky

This comment has been minimized.

jfbaraky commented Oct 30, 2018

When my debugger is turned off, the Realm didn't work and I cannot know why :(
Now my only option is to debug in slow motion.

@agurtovoy

This comment has been minimized.

agurtovoy commented Oct 30, 2018

@jfbaraky If you are on Mac, please try #491 (comment), it saved our sanity.

@cyphire

This comment has been minimized.

cyphire commented Oct 30, 2018

Hey - I develop on windows, and the others in my team on mac. I cannot use chrome debugger because of Realm. I even went to the amazing lengths of isolating all my realm queries, writes and updates to a single module (needed to be done anyway!), and put in the ability by config switch to open and close the realm for every call (in other words, even though we are in react-native and using javascript realm.io, I can open the db, make my query or updates, close the db and return an object which isn't realm but an array of objects. I wanted to see if it was Realm being open that was our issue. It seems that it's just doing something, anything in Realm which causes the slowness. Some simple queries and updates can take up to 25 seconds when the debugger is running, and they are almost instantaneous out of the debugger.

Because we use RealmSync for our project with the realm cloud, turning off and on the db wasn't production anyway, but I can test and develop with a local realm and turn on Sync for when we test for the cloud (production use).

This has to be solved. Every single field in every query, gets posted back and forth across the bridge taking up to 160ms each. A small query means 100's of them!

@jeshio

This comment has been minimized.

jeshio commented Nov 5, 2018

Guys, the team is actively working for this issue... now is year
2018-11-05_16-14-21
to infinity and beyond

@eaazumah

This comment has been minimized.

eaazumah commented Nov 5, 2018

Is there way of disabling Realm debuger???

@esutton

This comment has been minimized.

esutton commented Nov 5, 2018

@eaazumah Adding a way to disable Real debugger would be a great solution.

Sadly, I do not think it will happen.

@martsie

This comment has been minimized.

martsie commented Nov 5, 2018

Guys, the team is actively working for this issue... now is year
2018-11-05_16-14-21
to infinity and beyond

Getting that paragraph on the Readme was a win and took a bunch of back-and-forth in this thread. My understanding is that the realm team are waiting for react-native to change. It looks like Fabric may allow direct communication between js and native which would work with how realm works.

It's a waiting game now. Lets keep this thread alive so that other people don't waste time trying to figure out why their development environment slowed down - but otherwise I don't think there's much the realm team will do besides wait for Fabric. If you find other libraries like expo who are considering implementing Realm they need to be told about the debugging issues and sent to this thread so they can make an informed opinion.

@bmunkholm

This comment has been minimized.

Contributor

bmunkholm commented Nov 5, 2018

Fair point @jeshio, so I updated the readme to reflect reality.

I wish I could say more, but the current alternatives to Chrome, using Haul or Safari seems to be the best we can do until Facebook updates RN.

@esutton

This comment has been minimized.

esutton commented Nov 5, 2018

@martsie Adding a note to the README.MD is not what I consider "actively working" on this issue.

Sorry. I have no intention to be mean to anyone.

Passively waiting and "crossing your fingers" seems more accurate.

The current state is waiting for Facebook to change some debugging internals that may or may not improve Realm JS debugging performance. From what I understood from November 1, 2018, Blog · React Native - Facebook Engineering Blog, this rearchitecting will take more than one year to complete.

We're planning to land these projects throughout the next year or so

And after one or two years, can anyone say with 100% confidence that Realm JS debugging will work as well as debugging any other app that does not use Realm?

Something like this would help now:
Disable debug mode only for Realm in React Native? #2070

@csotiriou

This comment has been minimized.

csotiriou commented Nov 5, 2018

After seeing the new blog post on react native, it seems that the first steps have already been made-jsi has landed on the open source version of RN.

JSI is different than what Realm was hoping for, but it should help nonetheless. I would propose Realm to take a look at the RN 0.58 and see if it helps in any way when I officially lands.

@bmunkholm

This comment has been minimized.

Contributor

bmunkholm commented Nov 6, 2018

@csotiriou Thanks for the update! We will surely look into this.

@alexmbp

This comment has been minimized.

alexmbp commented Nov 14, 2018

In realm 2.19.0 I'm not able to use debug mode at all (_construct error), but can use in 2.17.0. Is that connected issues?

@kneth

This comment has been minimized.

Contributor

kneth commented Nov 14, 2018

@alexmbp Please post the entire error message. I have a hypothesis what we are missing but I would like to verify it.

@alexmbp

This comment has been minimized.

alexmbp commented Nov 14, 2018

@kneth actually same issue is already there:
#2053

Just to duplicate:
image

@csotiriou

This comment has been minimized.

csotiriou commented Nov 14, 2018

@alexmbp this is absolutely not the same issue.

This issue you mention appeared in 2.18. The issue discussed in this thread exists a long time now and it is an architectural one.

@kneth

This comment has been minimized.

Contributor

kneth commented Nov 15, 2018

@csotiriou @alexmbp Indeed, it is another issue. For some reason, we forgot to add _constructor to the debugging support library.

@alexmbp

This comment has been minimized.

alexmbp commented Nov 15, 2018

@kneth @csotiriou Thank you guys! I thought it's related because appears in debug mode.

@kneth

This comment has been minimized.

Contributor

kneth commented Nov 15, 2018

@alexmbp No worries! The reason I asked for the full error message was to confirm that it is a separate issue 😄

@abrarum

This comment has been minimized.

abrarum commented Nov 21, 2018

lol. This issue isn't fixed for pretty 3 years. WOW.

@kneth

This comment has been minimized.

Contributor

kneth commented Dec 6, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment