Not a specific programming query but more in relation to a javascript app as a whole having a general problem and looking for any possible solutions to debug it.
I'm using React and have a single page app which is receiving streaming data from a websocket about 40 times a second. The user display is updated a similar amount of times each second to show the updates.
The problem I'm having is that after running the page for more than 12 hours not only google chrome, but all of other applications start to freeze momentarily. If I start trying to do too much with the other applications, sometimes all windows on chrome will turn black and it can freeze for up to 30 seconds. The more processing/memory used by other applications and the more versions of the react app I have open, the faster the freezing starts, but in any case only starts after a few hours.
The only fix is currently to restart the whole of windows because even after closing chrome the problem persists.
I've tried using google chrome profiling to inspect the heap type to see a memory leak but the memory size is the same as when I first launched the app.
I've tried reinstalling chrome but this didn't fix the problem either.
I read somewhere online that freezing like this could be due to too much garbage collection? But what would be triggering this to happen in excess? And I don't understand why that would persist after I close google chrome.
A possible solution would be to build in an auto-refresher to refresh the page every hour once the user has been idle for at least 5 minute, but this seems a bit overkill if its a problem which can be solved.
Any tips/advice for debugging this kind of issue or obvious places I should search for a solution? as its very much un-shipable in its current state
The issue was due to one of the two following things on windows 10. I performed both and one of them has caused the freezing to stop:
1) In control Panel -> Power options -> additional power settings -> change plan settings -> change advanced settings-> change the hard-drive sleep option to never or 0
2) Updated chip-set drivers from the motherboard manufacturers website.
Related
I have created an application that uses Nuxt.js (SPA) to take up to 20 images taken with the iPhone and register all 20 at once.
When the images are taken, they are compressed to about 500KB using a library called browser-image-compression and retained.
The compressed images are then displayed in a preview.
The problem is that when registering 20 photos multiple times, the Nuxt.js application suddenly crashes in the middle of the process (when taking a photo, the captured image suddenly starts to disappear after loading, like when reloading).
Thinking it could be a memory leak, I tried measuring it on the Mac Safari timeline, but the memory usage goes up and up with each shot, and does not go down.
I tried to refresh memory with location.reload(true), but the memory usage did not go down.
Please let me know the solution to refresh the memory, or anything that will stop the application from crashing.
Memory Timeline just before the crash
Versions
iPhone 11
iOS 14.6
#nuxt/cli v2.14.12
Vue v2.6.14
browser-image-compression v1.0.14
There is a PR about this which aimed to fixed this exact bug. It maybe didn't fixed it really.
Please try to double-check the actual memory usage in another browser like Chrome or Firefox and see if it does the same. If it didn't, it's maybe time to give some feedback to browser-image-compression or use another package.
There are many instances where I leave a looped async function running on a chrome tab (for testing) but whenever I leave the lab, Chrome seems to significantly lessen the speed at which js runs on that tab. Is there any way to have full cpu power for running javascript on a different tab than that I am currently on?
For example, when I'm running a js test file on tab 1 with localhost:3000 but I go off another tab to do something else for a while. When I come back to tab 1, I see minimal progress.
https://developers.google.com/web/updates/2017/03/background_tabs
Background tabs can have a dramatic negative effect on browser performance, especially on battery life. To mitigate this, Chrome has been placing various restrictions on background tabs for the last several years.
...
Chrome provides the --disable-background-timer-throttling flag for use cases like running test suites and other user-sanctioned heavy computations.
So basically just launch chrome with the --disable-background-timer-throttling and you should be good to go
I'm building a web app that does a lot of DOM manipulation and uses CSS3 effects.
I'm repeatedly refreshing the page, and on every 4th or 5th reload, Chrome displays the Aw, snap page indicating a tab crash. I think the page is consistently crashing around that many refreshes, so I don't think it's a probabilistic thing, but rather stems from something building up.
How can I examine Chrome crashes to find out some potential culprit causes? I've tried taking CPU profiles and heap snapshots, and it doesn't look like I'm accumulating much memory.
We to are experiencing the same thing in latest chrome version 40.0.2214.111 on multiple computers.
We logged a bug with Chromium here: https://code.google.com/p/chromium/issues/detail?id=456365
Feel free to add comments / star to help get on their radar.
It seems tough to debug as there is no crash data and running debug tools themselves will cause crashes.
We have not been able to re-produce in Chrome Canary.
We were having the same issue using last version of chrome (40.0.2214.111).
In our case the app is using SoundJS and if we disable webaudio api for this library, the app is working ok.
if (navigator && navigator.userAgent && navigator.userAgent.match("40.0.2214.111")) {
createjs.Sound.registerPlugins([createjs.HTMLAudioPlugin]);
} else {
createjs.Sound.registerPlugins([createjs.WebAudioPlugin, createjs.HTMLAudioPlugin, createjs.FlashPlugin]);
}
don't know if your are using SoundJS but just in case I wanted to add this comment.
I've created a complex JavaScript web app. It works very well and is fast. But I've noticed that Firefox is continuously using the CPU while the app is open in the browser window but not doing anything. I haven't programmed in any setIntervals, setTimeouts, automatic regular requests to the server - nothing. The only thing it has is the GUI, which is already instantiated and sitting there doing nothing (since the last interaction with the user), and the event handlers which are waiting, attached to various GUI controls. Just to make sure, I used the profiler in Firebug and it confirmed that there was no activity to profile.
I did have 3 FF add-ons running: Avast Online Security, Firebug, and Web Developer. I have disabled these, and it seems to have reduced the CPU useage from say 4-5% to 1-2%. I know this is low, but considering I have only one tab open with my app in it, I would like to know where that 1-2% is being used. The memory consumption is not increasing (it fluctuates, but doesn't increase over time). I have done some quick checks with IE (9) but the CPU usage tends to stay at 0%.
I can't provide any code or solid starting points, but I just thought someone might have some ideas.
We have developed a Samsung Smart TV app for the 2011 & 2012 platforms. The app is HTML/JavaScript based. Normally the app is performing well, but after exiting the app becomes very slow, by a factor of six. The measured JS execution times are only slightly slower, but the HTML elements are rendered much slower to the screen. This behavior happens on all devices (TV and Blu-Ray Player devices with Smart TV Platform).
The exit is realized by executing the JS command
var widgetAPI = new Common.API.Widget();
widgetAPI.sendExitEvent();
The app behaves the same (i.e. becomes slower after starting again) when using the command
widgetAPI.sendReturnEvent();
(which returns the user to the Smart Hub instead of exiting completely). Through trial and error I discovered that making the app crash on purpose solves the problem - this results in an identical behaviour to the user as calling the sendExitEvent method. However, it is not a very clean method, and furthermore I would prefer to use the sendReturnEvent command.
How can I return the user to the Smart Hub programatically so that the app does not get slower when starting it again?
I hope somebody has some first-person experience and advice regarding this. I have tried to eliminate possible JS memory leak sources (using JS programming best practices and advice from Samsung), but that has not remedied the problem.
I solved the problem using two actions:
Instead of simply calling widgetAPI.sendReturnEvent() I redirect the user to a new page exit.html (using window.location.href), which is almost empty, except for an onload handler, which calls the following commands (which are equivalent to widgetApi.sendReadyEvent() and widgetApi.sendReturnEvent() but without needing to include the Widget.js file)
curWidget.setPreference("ready","true");
curWidget.setPreference("return","true");
Commenting out all alert commands. Apparently calling alert leaks memory when used several times so that the accumulated garbage is not collected from the memory when exiting the app, causing it to be slower after restart
Only applying the both methods seemed to fix the issue. Presumably the app accumulates memory leaks causing the app being slow after restart
1) on the document level (despite our efforts to follow all guidelines to prevent them), which are then purged after loading another HTML file.
2) on a global level, caused by calling alert