I have a chrome extension that is causing user's laptops to slow to a crawl and realllllly use a lot of CPU (or at least causes their fan to go nuts).
I'm wondering how I can profile this, or see what's going on.
Some theories to help guide:
extension needs (unfortunately) to do some polling. I won't go into why this is the case, but trust me that it does.
What this ends up looking like, however, is:
setTimeout(function() {
// our inner scrolling loop
scrollingTimerId = setInterval(function() {
// did the user change the URL?
if (!isModalUrl(window.location.href)) {
clearInterval(scrollingTimerId);
}
// scroll!
doScroll();
}, SCROLL_DELAY);
// our loop to check if we're done
isDoneTimerId = setInterval(function() {
...
}, OTHER_DELAY);
}, TIMEOUT_DELAY);
Perhaps there is some failture to cancel setInterval or something that's causing the usage to increase over time?
extension also sends messages to ALL tabs on certain events. Could this be an issue with multiple Chrome windows open?
Trying to hunt down what performance issues it could be, and also where to look. Perhaps there is a good tool I don't know about in the Chrome dev tools inspector?
Related
My Angular 2 Application is slow to respond (1-5 seconds) to key input, button clicks, tabbing across inputs, etc. only when Chrome Developer Tools is open. Material 2 animations also become slow and choppy.
I've been developing this application for three months, and use Chrome DevTools every day. This issue cropped up seemingly overnight.
What I know:
I stashed all pending application changes to revert my application to a time when this was not a problem. The issue persisted.
Chrome DevTools doesn't seem to slow down any other application (ie. google inbox, google maps) in the same browser session.
Maddeningly, when I run the DevTools' Timeline "Record" to try to gain visibility into the issue, the issue disappears and the page reacts at normal speed again! I assume this is the best clue that I have, but I don't know the internal workings of DevTools well enough to know how "Timeline Record" changes things.
I've restarted Chrome and deleted all cached data.
Nothing of the sort happens in Firefox or IE when I open the Developer tools in those.
Any recommendations on where to look next would be greatly appreciated!
Final answer:
Remove all breakpoints
Even if they're not getting hit this fixed it for me and got performance back to normal.
May be a bigger issue if you have logging breakpoints - so try deleting those first if you're attached to your breakpoints.
Previous answers:
I came up with a workaround - although still not really figured out what is actually wrong.
I also discovered a bunch of tools I didn't even know existed that I'd skipped over before - they're under More tools.
Start by opening the Performance Monitor. This shows a nice CPU graph isolated for your Chrome tab - the Windows task manager is as useless as it ever was.
This is the behavior I got when choosing a date from mat-calendar. No other logic running - just selecting a date. I removed everything from app-component and just put a mat-calendar and it took ten seconds to change the date!
Other controls are generally fine. I could open dialogs, use combo boxes etc. and nice and fast. But selecting a date gave me this nonsense:
I tried emptying local storage, clearing cache, etc. and then I changed port number for my website. I simply changed dev.example.com:44300 to dev.example.com:44301 - in other words Chrome now thought it was a different website.
This is what it looked like after I switched port number.
I also got the same effect using a reverse proxy server - which put my local machine on the internet - so I could try to duplicate the issue from other machines. I could not.
So hope that helps someone - still no clue what's in the cache for this server that is having such a massive impact on performance. But for sure it's not just my code.
Here's a few other things to try:
Test with --aot flag
This didn't make a difference to me, but good to narrow things down.
Add some controls that don't do anything (as a control)
This way you can find if some specific action or control is causing the slow down. You should of course be able to toggle these instantly.
Just toggle them on and off, hide something.
<mat-radio-group>
<mat-radio-button [value]="false">
bloop
</mat-radio-button>
<mat-radio-button [value]="false">
bloop bloop
</mat-radio-button>
</mat-radio-group>
Enable Rendering debugging options
Make sure you aren't re-rendering the whole page constantly
The rendering option above will show this to some extent, but one thing I like to do is just add a random text box - type in it and if the text subsequently disappears you know that control has been rerendered.
<!-- yes, just a standard text box -->
<input type="text"/>
Just hide things with *ngIf="false"
Hide controls (yours and third party) and see if anything is causing problems.
For me I'm currently suspecting mat-calendar is causing issues - but I'm still thoroughly confused as to why enabling 'Record' makes the problem non existent.
I've fixed the issue, but I'll never know what was causing it. Likely a setting that I had accidentally changed.
I deleted the Chrome App and reinstalled, everything is back to normal. I'm going to leave this question open in case anyone else has this problem or wants to contribute.
It is normal for every web app to run slowly with Chrome dev tools opened.
Especially if you have inspect tab open, that it's like a new page opened in the same time + has animations on any block render.
We had this issue today at a colleagues workstation. Turned out that it was a chrome-extension (don't remember, something with "ghost" in its name). So maybe try out using guest-mode and check whether the issue still occurs. If it doesn't, successively reactivate the extensions to see which one is causing the problems. If it still occurs, follow the other proposed approaches.
While browsing the web, I need to fake my screen resolution to websites I'm viewing but keep my viewport the same (Chrome's or FF's emulating doesn't solve my problem).
For instance, if I go to http://www.whatismyscreenresolution.com/ from a browser in full screen mode which has 1920x1080px resolution I want that site to think I am using 1024x728px but still be able to browse in full screen mode.
One of my guessess is I need to override js variables screen.width and screen.height somehow (or get rid of js completely but the particular site won't work with js disabled), but how? And would that be enough?
It's for anonymous purposes I hope I don't need to explain in detail. I need to look as one device even though I am accessing the site from various devices (Tor browser not an option - changes IP). The browser I'm using is firefox 30.0 and it runs on VPS (Xubuntu 14.04) I'm connecting to remotely.
This thread (Spoof JS Objects) brought me close but not quite enough, it remains unanswered. I've struggeled upon this question for quite a long time so any recommedation is highly appreciated!
The site you provided uses the following Javascript to determine which width/height values to show:
height = screen.height;
width = screen.width;
res = document.getElementById ('resolutionNumber');
res.innerHTML = width + " X " + height;
If all you care about is ensuring that these values change, you can do the following before their code is executed:
screen = new function() { this.width = 1; this.height = 2 }
If you care about other attributes of the screen object, you'll need some extra Javascript to preserve those.
To see this in action, load their page, then use Firefox or Chrome dev tools to put a debugger in their Javascript (line 116, where it says height = screen.height;), execute the above override, then press play!
If you want to do this for every page you visit, you'll need to incorporate this into a Chrome or Firefox Extension (I've made custom Chrome extensions, super easy).
Found a way, with firefox.
Go to the desired website
Access the tool by going to Tools -> Developer -> Responsive Web Design
Enter the resolution you preferred, then refresh the current tab, the website will reload the site according to the screen resolution you've set
By default, it gets shown only when the device's menu button is pressed and when the page is swiped down (see the GIF below when the touch marker is red). Can the URL bar be shown using JavaScript?
The solution
It is possible only on user input, because of the limitations of the Full Screen API. See the demo.
var p;
function showURLBar() {
p = [window.pageXOffset, window.pageYOffset];
document.documentElement.webkitRequestFullscreen();
setTimeout(function () {
document.webkitExitFullscreen();
setTimeout(function () {
scrollTo(p[0], p[1]);
}, 300);
}, 300);
}
Important notes
This function is tested only in Chrome 35.0.1916.141, on Samsung Galaxy S4, running Android 4.4.2.
On other devices, it might be necessary to increase the timeouts.
To avoid errors in other browsers, use a cross-browser implementation of the Full Screen API functions instead of webkit's.
This is kind of a hack, so it might become ineffective in future releases of Chrome.
Some lag can be seen because of the 600 ms timeout, but the function would be dysfunctional without it.
I've checked some other approaches without success. Changing the entire URL using window.location makes the address bar reappear, but leaving/reloading the page is an undesirable side effect. Changing only window.location.hash or using window.history doesn't help either, even if the URL is modified. None of window.scrollBy, window.scrollTo, window.scrollTop helps.
By the use of the word 'device' I'm guessing you mean a mobile device. I fought with this also and just used a shortcut to the page from the desktop of the device. Then you get full screen without the address bar.
I have a fairly extensive javascript that I can load in my Chrome (latest stable) and in IE11.
The load icon spins but the script eventually loads on my machine in both browsers.
I have 2 other people trying to load the page that contains the javascript in IE11 and they both cannot get the page to load. The loader icon spins forever and when they mouse over the refresh icon a flyout states "long running script"
How can I analyze my javascript to identify how and where the script is taking forever to load?
Chrome's Developer Tools (F12) can profile your code. This will give you a lot of information -- possibly a lot of noise -- but it will identify two things for sure 1) functions where a lot of time is spent, and 2) functions that are called often.
This is the first place I'd start: turn on the profiler and reload the page.
If that doesn't give you a good place to start, look into the Chrome Timeline and console.timeStamp( 'Some Note' ). After you have started recording a timing session, every time the code encounters "console.timeStamp", it will annotate the timeline allowing you to estimate elapsed time between one or more points in your execution. See here: https://developers.google.com/chrome-developer-tools/docs/console#measuring_how_long_something_takes
I have a page (A) which is a heavy javascript page, when I leave this page to go to page B it takes a long time. When I go to page B from a different page it is really fast. So it has something to do with page A and probably its javascript.
When I run the network profiler from the developer tools in IE 9 it shows a gap of ~15 seconds between the response and the DomContentLoaded(event).
Page A is heavy with javascript because it runs the Xopus Editor, a rich text XML editor.
Does anybody have any ideas on what I could do to either analyse the gap as to what happens or what I could do to make Page A unload faster.
This is a long shot as there are about eleventy-hundred things wrong with it, but it might be somewhere to start. Add this script tag to your page as the very last one:
<script>
function unloadJS() {
var scripts = document.getElementsByTagName("SCRIPT");
for (var index = 0; index < scripts.length - 1; index++)
{
var file = scripts[index].getAttribute("src");
var start = +new Date();
scripts[index].parentNode.replaceChild(document.createElement('script'),
scripts[index]);
var elapsed = +new Date() - start;
alert(file + ": " + elapsed.toString());
}
return false;
}
</script>
This code attempts to force the unload of each of the JavaScript files that were loaded on the page, reporting the amount of time it takes to drop them in milliseconds. Fire this as is convenient, i.e., on unload or with a button:
<button onclick="return unloadJS()">Go!</button>
This might not work/tell you what you need to know because IE could refuse to do garbage collection when the script is disconnected. This could be because IE really doesn't unload them when you do this, or just because IE - well, what oddi said :)
In any event, this isn't a solution; it doesn't matter when the JS gets unloaded, garbage collection still takes the same amount of time. This is just an attempt at a first diagnosis, like you asked for. Hope it works/helps...
Yes IE sucks. But there are several tools to profile your page.
Fiddler or HttpWatch is a good tool for analysing your request timeline and see whether it takes long time to download all your heavy javascript code. It's often the main cause of slowing down a heavey js page. Since IE doesn't take parallel downloading js very well, it costs more time for hundreds of small javascript files.
For this case, try minifying your javascript. It is the most direct way to enhance your page load performance.
If it doesn't help much. You may need YSlow to analyse a detailed performance. Although it doesn't fits IE, fixing some issues under Chrome or FF can affect performance under IE.
Add some log in your console, narrow down the scope maybe you can find the execution performance problem.
Maybe you're using a Javascript library like PrototypeJS that hooks onto the page unload event and when the page unloads, it loops through an array removing all the event listeners for all the DOM elements on the page. If we know what libraries you are using, we could simulate a call to unload the page to force the library to execute it's unload function. Afterwards, start a timer to see how long it takes to load another page.