realm / realm-js

Realm is a mobile database: an alternative to SQLite & key-value stores

Home Page:https://realm.io

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Chrome debug mode is Extremely slow

anativ opened this issue · comments

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

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.

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

@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

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

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.

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.

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.

@krzkaczor - we will definitely add this.

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.

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.

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

commented

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. ;)

commented

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

Any advancement in regard to this issue

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

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

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.

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?

Any news on the issue?

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

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.

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!

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

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

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

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.

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 :)

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.

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 :(

Pretty sure realm wants to know if they are losing customers over a developer pain point. They lost me over this one 🤷‍♂️

and me 😕

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!

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

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 :)

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

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 :(

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.

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.

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.

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.

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 😞

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

commented

Just leave Realm. It's dead project.

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

@alazier actually made some suggestions way back: #491 (comment). @fidelisrafael what else would you need to get started?

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

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

@fidelisrafael

I did the adb forward tcp:8082 tcp:8082 trick but this worked just for a few times...

if it worked and afterwards it is not maybe the adb server got stopped/killed and then the ports are not forwarded anymore. You can check the adb server is running when this happens. Also you can do this command to see if the adb server was not restarted in the meantime.
adb forward --list
if there are not port forwards then this means server was restarted and you can't attach a debugger to the device port until you do adb forward tcp:8082 tcp:8082 again.

This issue is for the case when you are able to attach the debugger but the debugging experience is not great since the debugger itself does a lot of requests for realm object's properties.

cheers

Thanks for tips @blagoev
@brunodahora @thiagoterleski you guys may want to know about this,

Assuming we can agree the debugger works, and we are "only" talking about it being unbearably slow, are any of you still up for trying to improve the speed? @fidelisrafael @martsie ?

#1274 may help with this (or may have close to no effect if it turns out that debugging was slow for different reasons than the tests).

Perhaps we can for the time being set a flag that returns the data rather than references to the data? It wouldn't be a direct solution to this issue, but might help in some use cases.

Any new solution / temporary solution?. Its really extremely slow in debugger mode on real device. very slow for development.

I almost chose realm...

I've been having a look at this in my spare time. It looks like the JS library is synchronous, all the RPC requests block the JS thread. Is that correct?

I experimented with adding the command:

RCT_EXPORT_METHOD(sendRpcMessage:(NSDictionary *)options
                  resolver:(RCTPromiseResolveBlock)resolve
                  rejecter:(RCTPromiseRejectBlock)reject)
{
    //NSNumber* jobId = options[@"jobId"];
    NSLog(@"send rpc message %@", options);
}

to the objective-c bridge and modifying rpc.js sendRequest to send the data directly to the objective C bridge but then I realised everything looks to be synchronous. If that's the case then no wonder it's slow!

Ideally, native code should return promises or callbacks using RCTPromiseResolveBlock or RCTResponseSenderBlock and the JS should response asynchronously to them. It looks like Realm is actually synchronous from the ground up, or at least the API looks that way - which is not optimal for single-threaded JavaScript applications. My guess is that Realm was never designed with JavaScript in mind and ported across.

Please feel free to correct anything I said above, I might be off the mark. It's a fairly complex module to get my head around and understand and I'm by no means a database expert.

+1

I'm also facing the same problem. Chrome debugging becomes extremely slow and unusable after integrating realm.
Thinking of dropping realm to gain back my debugger

commented

+1

This is really cutting debug productivity. Using adb logging as a work-around is terribly inefficient and I too am considering switching to alternatives to realm for this reason.

Compared to slowing down the debugging for the entire app, the time required to switch away from realm is a low cost to pay.

Having to fall back to logging has a terrible cost in loss of development productivity.

reactotron has been working well for me all this time.

this should be highlighted at the main page, its a deal breaker that this library slows down the debugger to the point of unusable.

I’m upset that I had wasted many hours getting realm to work in my app, now had to tear it down.

Let this be a lesson to all those wanting to use realm, should have stick to the true and tested sqlite

Good idea @edward-s , I've raised a pull request at #1508 to address this issue.

Update: I attempted to add a pull request to the Readme file to inform developers that debugging would be affected by Realm and a developer closed the pull request without merging.

The suggestion to put a notice in the readme.md is ok if we don't find a good solution to the issue. And the issue was labeled "In Active Progress' to notify all we are looking into it. Let's leave the readme.md change as a fallback if we don't find a way to fix this.

At our weekly meeting we decided to add a disclaimer about the debugging issue similar to the one proposed. Here is a PR for that #1515. We have dedicated resources to investigate and act on the issue so it is In Active Progress state. We will post updates here.

As always any help from the community is highly appreciated.

cheers
blagoev

Aw... thats why i have to wait about 4 mins until i can finally debug on vs code (which uses chrome debugger) !

Meanwhile i've been using https://github.com/jhen0409/react-native-debugger ever since i started react native 10 months ago. Not too bad, still get some lags here and there i figured it was caused by realm.

commented

@wilomgfx I just tried https://github.com/jhen0409/react-native-debugger and it takes the same 5 minutes to load my app when Remote JS Debugging.

I use a mixture of Genymotion and real devices for Android development.

How to Debug Your App If You Use Realm

  1. Stare at your white screen emulator waiting for app load. ( It literally takes 5 minutes )
  2. Make quick code change
  3. Press Reload to test, go to step 1 and wait 5 minutes, repeat
		"react": "^16.0.0",
		"react-native": "^0.50.3",
		"realm": "^2.0.12",

Work-Around:

None. Anybody?

Both Chrome debugger and react-native-debugger take 5 minutes to load after every code change.
It is not debugging realm usage that is the problem. My app uses 50 dependencies. I must use adb to debug the entire app.

While waiting, you can watch thousands of ~50 millisecond get_Property calls scroll by in the Network tab while you wait to test your code change.
screen shot 2017-12-05 at 3 12 56 pm

Can someone reproduce 100% CPU after reloading the react native app with CMD + R in iOS Simulator without the debugger open? Trying to debug this for days and I have the feeling realm is responsible.

Edit: Found it. Don't pass realm results as props. Issue came up when network speed was limited. Used Additional Tools for XCode to Debug. Happy Coding!

Folks, we know the debugging experience in React Native apps with Realm is unusable to the point of being broken. We've tried to come up with small fixes and improvements, but nothing we've been able to do has adequately addressed the performance issues a moderately-sized app using Realm experiences in the Chrome debugger. I'll try to shed light on the causes for this as transparently as possible below, and outline the possible ways forward that we've identified.

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. This allows us to offer fast and convenient APIs to work with Realm inside the worker thread without impacting the main UI thread in any way (though Realm was designed from the ground up to be able to run on the main thread in native iOS and Android apps with minimal performance impact to begin with).
The React Native Chrome Debugger builds on top of the bridge - in this case the application's (and all its modules') JavaScript code runs inside Chrome and the native code runs on the device, with a websocket between the two for the JSON messages to flow through. This breaks Realm because in this case there is no JavaScript context whatsoever for it to attach to - JavaScript runs in another process on another machine. That's why Realm has a Remote Procedure Call layer that runs alongside the React Native debugger. It's implemented on top of blocking XMLHttpRequests that emulate the synchronous Realm API. Every time the Realm API is hit, even for a thing as small as a property access on a Realm object, a blocking request is fired that takes dozens of milliseconds to complete. The more you use Realm, the more your application spends time blocked when running in the React Native debugger.

Possible ways forward

1. React Native switches to a proper remote debugger

Our ideal scenario is one where React Native ditches the current Chrome debugger implementation where JavaScript runs inside Chrome and not on the device. This is how the Node.js and Electron debuggers work, as well as every browser debugger ever. Realm runs just fine inside the Node.js debugger with no apparent slowness, and the same should apply for a hypothetical React Native remote debugger. We already know it's possible to implement such a debugger because NativeScript - which uses the same JavaScript engine as React Native, has already done so.
This would have broad benefits for React Native as a whole as it would make debugged applications run much the same way as regular applications - it would run under the same JavaScript engine, on the same device. Right now a React Native application running on a low-end Android device is bafflingly faster when debugged, because then its JavaScript code runs on a desktop machine with a quad-core processor. But most importantly for us it would make Realm work inside a React Native app that's being debugged the same way it works in production.
There are hints that maybe React Native is going to get such a debugger - the facebook::react::IInspector interface looks just like JavaScriptCore's Remote Inspector, but I've yet to see this intention be confirmed on a public forum.

2. Reimplement Realm from the ground up as a React Native module

It is possible to implement Realm on top of the React Native bridge, if we sacrifice everything that makes Realm what it is. All the APIs will need to be asynchronous, and we will lose key features such as live objects and zero-copy because everything will need to be serialized as JSON back and forth. Realm for React Native will become like any other remote database. On the plus side, debugging will "just work" because everything will use the React Native bridge which is already handled by the Chrome debugger.

3. Try to cache things inside the RPC debugger

Right now every time a Realm API or object is accessed a blocking HTTP request is fired to the RPC debugger server running on the device. It should be possible to cache some of the data accessed locally instead of hitting RPC every time. However, we believe that this approach is potentially error-prone and hard to implement. There are lots of potential issues with cache staleness that would make the debugger so unreliable it would be as unusable as it is today.


Right now the approaches detailed in point 2 and point 3 require engineering resources our team does not have at the moment, and will detract from the ideal experience of using Realm by either degrading APIs or introducing subtle debugging bugs. Our best hope is point 1 because it requires little to no engineering effort on our part, does not compromise the way Realm runs outside a debugger in any way, and completely solves the performance issue when running inside a debugger.

Let me reiterate - we think that the best outcome is that React Native implements a new debugger on top of the JavaScriptCore Remote Inspector protocol. My personal research leads me to believe that such efforts are already underway. Is there a member of the community who knows more on the subject?

Thanks for the clear an ddetailed answer. Now that the debugger disclaimer and this detailed response is up, future devs will be able to make a really informed decision on whether or not to use Realm (for the record, one of my projects uses Realm which is why I was so vocal on this thread).

I did a quick Google and wasn't able to find anything on point 1. If anybody finds any issues to track regarding on device javascript debugging for react native then plz post it here as I'm keen to track it.

@fealebenpae Thanks for being transparent, that's really cool and I learned new things with your contextualization, nice!!
For me the option 1 looks the "ideal" way, but this is not in control of Realm so it can take a while...or never happen, otherwise option 3 looks complex, but more "possible": Cache is so easy to save, really hard to invalidate correct...but if this can solve the debugging problem and develop this as a separated lib(something "temporary") this may be a solution for now. (I mean, some kind of "monkey patch" to open the RPC functions inside RealmJS and force caching only for DEVELOPMENT, in production this new lib can be removed to avoid conflicts..)

Any news about this issue?

Why don't we create a database manager for debugging easily Realm? It will be easier to debug, manage, have a global sight of the current db state. Here is a good inspiration: http://mongotron.io

Anyway, if anybody has a plan, I can get involved as well. We need to fix this by 2018.

@popo63301 What's the feature you would want from that? How is it different than Realm Studio? I'm not sure I understand how that would solve this problem?

@bmunkholm I didn't know Realm Studio existed. I need to check it out if it works well with React Native. I think a management interface helps to modify the content of the db "on the go". It can helps to create mock data to test things out. I don't know if Realm Studio has performance issues like the Chrome debugger though.

Anyway, is there anything new with this issue? 😄

@popo63301 Realm Studio works very well with all SDKs. It can open local files as well as remote (Realm Object Server hosted) and you can inspect and change data as you like. Besides import/export and schema editing :-)

Unfortunately there is no other news regarding this core issue :-(

FWIW: I am able to run and debug iOS app using Safari dev tools. Instead of clicking "Debug JS remotely" I attached Safari's debugger to a JS context running in the iOS Simulator. Also, I switched to Haul to get source maps working with react-native JS debugging turned off.

If you're stuck with realm and had to debug iOS app, then it should make your life easier.

You really need to delete this marketing hype until you can actually debug without everything crawling to halt on a middle to large size dataset.
https://realm.io/blog/introducing-realm-react-native/
This was so promising until I hit this issue. Realm solves a ton of problems, but I cannot hamstring the debugging workflow like this .. so I have to pass on the platform.

commented

@bitfrost I would have looked hard for alternatives had I known. Too late for me. :-(

My app freezes on Debug JS after a couple of reloads.

One could be hopeful that https://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018 will enable proper debugging. Not sure about the actual changes though...

Using realm in a separate thread with react-native-threads does speed things up, at least I was having a lot of performance issues, until I decided to use realm only as a persistent store on a different thread.

It also improves performance while debugging. The only thing that you will not be able to debug is your query thread, which is fine, since all it does is use realm.

That implies, you will loose zero-copy, and live views, and that you have to copy the results manually over to the main thread, but I am mostly interested in the POJO model definition (like most ORMs), and the simple query language.

  • Mutable live views are a bad idea with redux.
  • Synchronous I/O is a bad idea in javascript.

So, it does sound like you loose stuff, but you actually gain a nice db layer, that conforms to JS conventions.

@galileopy can you expand more on your approach. How are you sending commands into the new thread JSON?

@scottwio , I'm using JSON to pass around commands and results, which does remove the whole "zero-copy", "feature", and I'm using a sort of improvised memory work queue to know when to resolve the right Promise with the results.

I have published a gist, with the basics of how it is implemented right now, I have stripped it of some application specific parts, so it might have some syntax errors.

Please be aware this is a work in progress, gist

If you're specifically using React/Redux, and you're just starting out I would recommend to look around for other options, I went the extra mile just because I had to finish a demo with a crazy deadline, and I had already invested some code in realm.

I will drop realm once I have all the UIX implemented.

For anyone who is on Mac and is looking for a slightly more sane way to debug their code while the Realm/React Native teams are working on addressing this:

You can use built-in Safari debugger (essentially what @fealebenpae called "proper remote debugger" earlier) to debug your React Native app "in place", without attaching React Native "remote debugger".

Since your code is executed on the actual device (rather than in Chrome), the performance is much more bearable, and, as an added bonus, you don't have to deal with subtle differences between the JS environments.

To attach Safari debugger to your RN app, simply launch Safari while your app is running in the Simulator, then go to Develop > Simulator > <Your App's name> > JSContext:

safari-remote-debugging

Two major downsides of this approach are:

  • No source maps, all your code is transpiled (but not minimized) and is shown as one giant bundle.
  • Every time you do "Reload", Safari adds a new "JSContext" menu item; the one you want is at the end of the list. This one might drive you nuts, but probably not as much as the slowness of the Chrome debugger.

Thanks a bunch for providing those instructions @agurtovoy !

@galileopy here realm not works fine with react-native-threads has some issue when instancing threads. Have you figured yet some issue too?

@joaom182 This does not seem related to this issue about slow chrome debugging?

@bmunkholm as the sugestions of @galileopy to use react-native-threads it's important to this topic to alert about issues with realm + react-native-threads

@joaom182 I do agree with @bmunkholm that this is not relevant to the issue, since is a workaround that comes with a big bag of consequences about the way realm should be used. I suggest that you prepare a SO question with all the details relevant with your setup and what doesn't work properly. All I did was follow the instructions on the react-native-threads README.md, it is very likely that you missed a step.

Is there no way to disable all the realm debugging? I can live without debugging realm so long as i can use the debugger for other stuff.

Setting mobile device time ahead some seconds from computer system time, solved the slowless issue for me, as this post describe
https://stackoverflow.com/questions/42142933/react-native-debugger-is-too-slow/51690840#51690840

This is getting ridiculous, after 2 years this problem is still happening.

@thijssteel The slowness comes from keeping the Chrome debugger up to date since Realm is running on the device or emulator. If you are debugging a part of the app which does not involve Realm, I can see your point. But I am not so certain if it is easy to disable it so easily.

commented

Is there no way to disable all the realm debugging? I can live without debugging realm so long as i can use the debugger for other stuff.

@kneth I think almost all developers using realm-js would be very, very, happy with @thijssteel suggestion to add a way to disable the realm Chrome debugging.

Could someone please look into this?

Even if I you have to comment out some realm-js code and re-build, or make your own realm-js fork and remove the Chrome debug code, it would be extremely valuable to be able to Chrome debug again like the days before I added realm to my app.

As it is, if you have a react native app that uses realm, Chrome debugging practically 100% broken for development. Because of this issue, I must use to console.logs to debug anything.