When developing my react app the app becomes unusably slow with the devtools open in chrome. Works fast and fine with them closed or in incognito mode. I have tried disabling all extensions and had the same problem. This seems to have started happening recently when I updated chrome (now on Version 80.0.3987.132).
I am not really sure where to start debugging this issue but it has become very frustrating to develop on my app.
Any advice or help debugging would be appreciated.
TL;DR: Go to the Sources tab and delete all breakpoints for the site.
I had a similar problem. My site was very slow to load, but only in specific circumstances:
Dev-tools were open.
Tab was in a normal window. (not incognito mode)
Profiling was not enabled.
If (and only if) all three of those conditions were met, the site would load unbearably slowly (15+ seconds; normally ~3s), plus have performance issues for certain operations on the site (like changing which subpanel was open). It was very strange.
Like you, I tried disabling all of my extensions, yet the problem persisted.
Attempt 1: I tried clearing all of the site's cookies and local-storage, using the info/lock dropdown at the left of the address-bar. Suprisingly, that seems to have fixed it! (edit: this was not the root problem; see below for that)
So the problem must be that my site was storing too much data in local storage or something, such that dev-tools was choking on it (but only in specific cases, for some reason). This also matches with the issue resolving in incognito mode: incognito mode uses a "clear slate" for site cookies/local-storage.
Anyway, it's an odd one, but the cookies/local-storage clearing seems to have worked for my case. (If the issue comes up again, and the solution above doesn't fix it, I'll try to remember to mention it.)
Update: Oddly, having the profiler on still speeds things up even after the fix (ie. those three conditions being met still slows down page loading and actions, just much less than before the fix). So apparently the fix merely "reduces the intensity" of the problem rather than fully fixing it; like, by resetting local-storage, it lessens the size of that data, which somehow is a variable affecting the core problem (not yet identified).
Attempt 2: I believe I have found the root problem and solution: I removed all breakpoints for the site, and the slowdown was solved completely. So the problem seems to be that I had lots of unneeded breakpoints set at various places in my website code (some enabled, some disabled). Some of these must have been placed in/near "hotspots" that were getting called frequently. By having the dev-tools open, the Javascript engine must have had to start performing some processing related to the breakpoints, slowing things down.
My guess is that the problem would also be fixed by disabling the "JavaScript source maps" settings (as that's the only thing I can think would cause so much slowdown), but I haven't confirmed this.
This has most probably something to do with this commit, titled "Stop sending profile data when recording is off".
They already know there is an issue with the Developer Tools slowing down and they tried to prevent it by preventing profiling data to be sent via the bridge to the frontend, when not recording.
As reported, it seems the issue is not happening anymore, on the latest version. However, the cause is still unknown.
Try uninstalling the Developer Tools extension, clearing browser cache and then installing it again.
You should probably try using a version other than the one you're using, Version 80.0.3987.132. The app you are trying to develop might not be suitable to the version you are using. Delete the extension you are using, clear and remove every trace of browser cache and then re-download the extension, like what Daniele Molinari said. It might help. If it doesn't let me know. I'll try a different approach.
Related
We have a reactJs application which works fine on all other browsers except safari on macOS and ios. The app works perfectly on Chrome on macOs or windows and ios as well.
Also, once the app freezes, we cannot open dev console in safari and if it is open, most of the things don't work like pausing script execution. And we can say from activity monitor that it goes in some infinite loop as the cpu usage of that page goes to 100% but i am unable to figure out as there are no errors at all and it works on other browsers.
It just freezes on loading and becomes totally unresponsive (No scroll or clicks etc). It looks like there is some infinite loop or dependency issue.
The webapp is kind of LMS and has many dependencies but to give you an idea here is the stack -
GraphQL
React Router Dom
React Hooks
Sentry for Logging
Socket
etc
If you have any questions feel free to ask.
Here is the site - https://i3.stage.cudy.co/
Thanks
I went into trying to see what's going on and I noticed three things:
First couple of times I tried to open your site it froze as you say. Could not even open dev tools.
After previous tries, I suddenly saw the icons for your menu options (browse tutors, assignments, feeds, etc) appear and everything worked "fine" and no more freezes.
However, I did noticed a bunch of errors in dev tools. Most of them are related to urls not allowed to access and some others due a /profiles trying to access an API of some sort.
You have a lot of unhandled promise rejections errors in your *.js so that may also be something to look at.
I would suggest tackling down the cross domain origin policies first and then add logic to handle the promise rejections that you're missing since sometimes those unhandled scenarios leave the app at the dark without knowing what to do and may interrupt your logic process thus rendering frozen sites because of that.
Last but not less important, this is a good way of tracing down the issue.
There are way too many factors involved for us to help you without looking at the code.
I'd recommend the following:
Going through the code history and testing it on each major version change so you can rule out any culprits or suspicions.
I'd disconnect any packages 1 by 1.
Disconnect the API so see if it's a server issue where you're requesting API calls infinitely or something silly like that.
If disconnecting the API works then you know where to look at.
Cheers
I've been working on an app I'm building, and until now it's had a reasonably small footprint. Today, however, I was looking into why my computer was suddenly running slowly, and I can see the app in Chrome is occupying around 1.2 GB of RAM!
Looking through my commits, I can't really spot anything suspicious. Where should I look when trying to debug enormous memory usage? I'd post code examples, but I can't see anything relevant, really.
To check what React is doing, try go get a snapshot of your app using the React profiler: Introducing the React Profiler
For everything else, try checking out the built-in profiler in the Chrome developer tools: Chrome DevTools: JavaScript CPU Profiling in Chrome 58
Those should be two good starting points to look at.
Sorry, we might need some more clarification about what you've tried.
It could be a ton of things. Most likely you're storing some sort data from the server or have some sort of memory leak (like adding something to a collection, but never deleting it).
One thing you can do is use the Chrome profiler to see when your memory climbs:
(This can be found in the drawer that open when you push Esc.)
The "Performance" tab can also be nice if you want to view the memory on pageload (using the 🔄button). Just make sure that memory is checked.
This is a weird one I've only recently noticed since Chrome 60.0.3112.90 on Mac OS X 10.11.6, and it really impacts my daily work.
Chrome is creating a new console context every time an Angular application is reloaded, and the previous instances (presumably) stick around. This makes working in the console difficult because the context of the console sometimes remains on an old context. Whats worse is you cannot even interact with an old context so why does it remain?
I'm unsure if this is a UI bug or an actual issue with the Angular application possibly keeping reference to something from the previous context (not sure how or what would even do that).
This occurs on both the product I work on, and on the Angular documentation website.
Here's a gif of it happening:
http://i.imgur.com/lVjLJnu.gifv
Every time you see me click outside of the console, I'm performing a reload.
Any ideas? This is absolutely obnoxious. I've disabled all extensions with no difference. My colleagues on Linux do not have this problem.
I have a weird issue with my BigQuery UI (going on https://bigquery.cloud.google.com/queries/my-project-name). I don't know why, but I see no datasets for my projects, when I'm fully aware they exist. My code can still hit these datasets and their tables. There is just no way for me to see them.
In the UI itself, I can still query them if I type the whole query by hand, but being able to see my structure for my schema could be helpful.
When I check my network tab in the developer tools on chrome, I notice that I receive "Failed to load ressource: net::ERR_CACHE_MISS". I then decided to do everything I could to reset my own cache. I cleared my cookies, went incognito, I tried other browsers, even other computers. NOTHING brings back my datasets.
Anyone encountered this and has any ideas how to force my cache to hit?
I had the same problem a while back. When I got the error, I struggled with it and I ended up finding a way to reset this. Seems like it's something cached server-side that makes this incorrect cache-hit. The way to reset the server-side cache is to hit a URL with a project that doesn't exist, so something like https://bigquery.cloud.google.com/queries/bogus-nonexistant-project should reset it all
Did you recently assign a new string ID to your project that previously only had a numeric ID? If so, this is a known issue that has been reported recently, and I'm still working to resolve.
The issue is that the frontend cache gets stuck with the old numeric ID for the project and our frontend JS has a bug where it errors out instead of updating the cache to contain the new string ID. LiY's workaround of going to a bogus, uncacheable URL is the suggested workaround to unstick the cache until this bug is resolved.
(And if you didn't recently assign a new string ID to your project, then I'd love to hear more details about what might have caused this issue so it won't happen to anyone else!)
I have a standalone WPF application running on .NET 3.5. Every so often, the display simply freezes up for several seconds. This is most noticeable on screens where something is being updated often. Here is a video showing the problem.
While the display is frozen, the interface remains responsive (video).
I've come across some other posts with similar problems who attributed it to a SW/HW rendering issue. To be safe, I disabled HW rendering altogether, but still have the problem.
I ran a file monitor during the freezes to see if there is some extraordinary file access or activity going on, but nothing is out of the ordinary.
Final note: The target platform is a small touch-screen panel PC without much memory or horsepower (512 MB). I only see this issue on the target, never on my development PC, which has much more in the way of resources.
UPDATE
I thought I had fixed the issue by removing some animation code, but it did not work. I am still encountering the problem and I'm at the end of my rope.
Here's some more things I've tried:
Upgraded to .NET 4.0. Same behavior.
Added debug code to all methods that may be invoked via DispatcherTimer (which are called on the UI thread) to make sure none of them are holding up the UI.
I'm really stumped here and have added a bounty. As I mentioned, the problem only occurs on the target PC (link).
I tend to suspect either .NET GC or the OS swapfile when this kind of behavior shows up.
For the former, you could try the .NET performance counters to monitor for suspect activity.
If the device has a swap file, you can disable it and see if the behavior changes.
As others have said, a profiler (or some what of isolating what condition is inducing the delay - even just attaching and breaking the debugger when it occurs) would be a good way to get more information.
Did you tried to profile the application on the tested system? Using a memory and/or performance profiler?
You could get some good informations out of this type of test : some .Net profilers
And here's one for WPF : WPF profiler from microsoft
The culprit was the following method call:
new HwndSource(new HwndSourceParameters());
This was added to my application because it patched a memory leak problem in .NET 3.5. This work-around can be found here. If I remove this call, the rendering issues go away.
I took out the call and fixed the memory leak in another way (removing storyboard animation and using code behind instead)