Related
I have a very large javascript application, which contains mostly asm.js code (it's built upon urho3d c++ engine which is them compiled into asm.js).
It runs great on most browsers (chrome, firefox, safari, edge) but is extremely slow on IE11. The thing is, it is only slow until you open developer tools. With developer tools open, IE11 becomes ~10 times faster and is almost as fast as other browsers.
Here is a minimal example that reproduces the issue:
http://test.sebbia.com/urho3d/test.html
Open the page in any working browser, the time between "Run - start" message and "Run - finish" message should be around 1-2 seconds.
Open the page in IE11 without developer tools, time should be around 35-50 seconds.
Open developer tools and reload, time should be around 2-3 seconds.
Another important note is that if I start profiling session in developer tools, performance drops like if developer tools were closed. So I can actually profile the problem. But I've spent several hours profiling and I've tried inserting log messages in big functions but I haven't found no bottleneck. All functions take roughly the same time to execute and if I insert log message in a middle of a big functions, they'll usually break into 2 similar parts. So there is no single function that is responsible for slowdown, the code execution is just slow. Bit shifts, functions calls, arithmetic operations - it seems like they all just take way too much time compared to open developer tools.
I really need to make my app work on IE11 and the fact that it works with developer tools open drives me crazy. I'm trying to find a way to make IE think that tools are open even when they are not, or achieve good performance by any other means. So my questions is how can I achieve performance equal to IE11 with developer tools open without actually manually opening the tools?
This is a very broad question so I'd like to break it down into several smaller questions:
Is there a way to make IE11 think developer tools are open? Maybe there is something like x-ua-compatible meta tag I am missing?
What's causing the slowdown when developer tools are closed? I've heard that console.log function calls are slow without developer tools on IE8 and 9, maybe there is a similar thing on IE11? Maybe asm.js is not optimized? If I knew what's causing this I could at least try to rewrite code to avoid this.
Is there a way to open developer tools from javascript code? Maybe I could ask users to press a button on website to "make app faster". Asking them to press F12 or navigate settings seems too much.
When the debugger is enabled, asm.js compilation will be disabled and execution will fallback to be executed as normal JS - you can see the console.logs along these lines at the start of execution.
asm.js has been disabled as the script debugger is connected. Disconnect the debugger to enable asm.js. in Edge,
asm.js type error: Disabled by debugger in Firefox,
whilst Chrome will simply not open 01_HelloWorld.js in the debugger when you attempt to.
Disabling the debugger in IE (debugger tab, socket symbol; eighth from the left), and thus enabling asm.js will allow you to have dev tools open but see the slower execution. I have a horrible feeling that the slowdown when the debugger is closed is actually just IE11's speed issues with asm.js's optimisations.
There are a lot of references to IE11 being poorly optimised for asm.js. caniuse.com goes as far as listing IE11 as not supporting asm.js at all.
https://caniuse.com/#feat=asmjs
This appears to be backed up by Microsoft themselves:
https://developer.microsoft.com/en-us/microsoft-edge/platform/status/asmjs/
There would certainly appear to be some support for it, though clearly it has a number of speed issues as demonstrated in a number of benchmarks, for instance:
https://github.com/Kukunin/asm.js-benchmark/blob/master/README.md
Which shows IE11 around 10x slower than other browsers, or:
https://www.ghacks.net/2014/11/03/massive-benchmark-highlights-asm-js-performance-of-web-browsers/
Which is based on:
https://kripken.github.io/Massive/ - You can try it for yourself.
And many others. It may simply be that the IE11 implementation of asm.js is so poor that it is considerably slower with it, than without it.
EDIT: Added Microsoft platform status link.
There are two workaround for this issue:
to add setInterval(30000, () => {}) to your initialization function;
add MutationObserver=null to the beginning of the main html
You can also reference the discussion here:
https://github.com/OfficeDev/office-js/issues/521
This is just a guess but I had a similar problem in react-native then I found out about this:
When debugging remotely, your js bundle is using chrome's JSC and when
running on a device it's using the JSC provided by Apple on your phone.
Make sure that urho3d is not changing environment when developer tools are on/off.
I'm not a Windows Phone developer, and I want as little to do as possible with anything related to Microsoft. Nonetheless, I need to get my mobile web app running properly on Windows Phone 7. What debugging tools are available for the platform? Something like the Webkit developer tools or Firebug would be ideal, either from the phone itself or more likely, remotely debugging from my computer.
If such a thing doesn't exist, I'd settle for being able to read Javascript error messages, and view the contents of variables using alert() or similar. At this point, all I know is that my JS is failing: I don't know where or why, let alone how to fix it.
My dev computer is running OS X, and I'd really like to be able to use these tools from OS X if possible. Assuming that debugging tools exist (which I really hope they do) are they designed for Windows only? If so, does anyone know how well they would work with Wine or similar?
EDIT: I have a physical Windows Phone 7 device, so I can use that. However, alert() doesn't seem to be working, which is why I'm posting this question. Does alert() normally work on the WP7 browser?
You'll likely find the Mobile Perf Bookmarklet to be the easiest all-in-one tool for testing any mobile device.
Works well on the iPhone/iPad/Samsung Galaxy Tab in my testing so far.
Quote:
It displays a menu with links that load other bookmarklets including Firebug Lite, Page Resources, DOM Monster, SpriteMe, CSSess, and Zoompf.
Unless you have a Windows Phone 7 device, you will need to run Windows in BootCamp and install the Windows Phone Developer Tools in order to test in IE on the emulator. I don't know about Whine, but I ran into major problems trying to test in Parallels - so based on my experience, I suggest keeping it as simple as possible.
There is no console in IE on the phone, so you will need to use alert, like you suggested, or just write text to a div on your page as a custom console.
If you really want to code in OS X (which I definitely understand), using a separate machine for testing IE in the WP7 emulator is going to be your best bet.
EDIT: I just tested alert and it did work fine on my Windows Phone. My guess is that a syntax error is preventing it from calling.
The following may be interesting
Simple IE debug tool for Windows Phone
Supports
Html traversing
Html node styles, properties, metrics
Reading console output
Executing js on device side from console (including intellisense)
Dynamic script injection - ability to debug live sites
Not supported
js breakpoints
Just wanted to add a note to say that full JavaScript debugging is possible now with Windows Phone 8.1 and Visual Studio 2013 Update 2. Full details are available at:
http://blogs.msdn.com/b/visualstudioalm/archive/2014/04/04/diagnosing-mobile-website-issues-on-windows-phone-8-1-with-visual-studio.aspx
I realize that this doesn't help the versions referenced in the original question (WP7), but I'm hoping this will help people who may find this question and are running a more recent version.
Something that has worked for me, is to test my mobile pages through the Windows Vista built-in Internet Explorer browser.
It comes with a script debugger ( which you have to enable in Advanced Options tab through the Internet Options menu ), and it seems that it gets really close to the Internet Explorer Mobile implementation.
Another tip would be, that, instead of using window.alerts, you can also use document.write or set output to a div content.
I'm using this hack to have console.log send info back to the server (it uses window.fetch, which I'm polyfilling, but could use xhr instead) https://gist.github.com/wheresrhys/bf93057ee3a594454582
I have a large, javascript heavy web app that I am working on. I am experiencing very slow response times from Chrome Dev Tools for XHR responses and console loggging (3-5 secs). The actual app is running fast and responsive, only dev tools looks like it is suffering.
Does anyone have any idea why Chrome Dev Tools is becoming sluggish as my app grows?
Devtools are like any other debugger; they hook into the normal processing flow of an application, and store quite a bit more information than is normally required. This is much more work than simply rendering the page without debugging enabled, so it will indeed be slower.
That said, 3 seconds to respond to console.log seems high. I'd suggest that you first test the application in a nightly version of WebKit. If it's responsive in WebKit, but not in Chrome, please file a bug against the inspector via http://new.crbug.com/ along with any information you can provide about what scenario causes the slowness.
If it's equally sluggish in WebKit, please file a bug against WebKit's Inspector component: https://bugs.webkit.org/enter_bug.cgi
Either way, post the bug ID here, and I'll see that it's triaged into the correct team.
I "fixed" the slow chrome developer tool by (under SOURCES tab)
clearing the "watch" list that accumulated over time...
clearing all the "snippets", i had dozens as well...
Not sure which of both made the most difference, but it certainly made a difference
This is an old question, but it may help someone landing here later like I did.
Using Chrome 46.x/47.x on Linux (RHEL 7), none of the proposed solutions worked for me. What did work was to disable the setting "Use hardware acceleration when available", in the advanced browser settings.
I noticed in the process monitor/list that the Chrome renderer was taking up a lot of CPU, even putting a breakpoint or stepping throught statements in the debugger would take 10+ seconds!
Might be worth a shot.
Undock the developer tools into separate window.
In my case, it's work.
I struggled with this also, to the point where stepping through code using the chrome debugger was just so slow it took hours away from my productive development time. In watching the CPU utilization when debugging in chrome I would see it use up to as much at 40% of all 4 cores of my processor. I tried everything to no avail. Finally, I tried making the browser window of the page I was debugging as small as I could without losing any of the required view and miraculously it solved the problem. So, now I keep my debugger window popped out in a separate window, and make the window of the page I am debugging as small as I can and my debugging experience is very fast again. I have tested this over a period of weeks and it has held out. Hope this helps someone.
I have a webpage that heavily uses Javascript (AJAX requests, Google Maps API, HTML building, etc) and the page brings my PC to its knees whenever opened in Internet Explorer. I'm looking for some tools to help me find out which functions are taking the most time to finish. I have some basic profiling javascript functions, but those don't help much considering I don't know what function specifically is being slow. The tool has to be for IE, as the page runs fine in other browsers.
For JavaScript, XmlHttpRequest, DOM Access, Rendering Times and Network traffic for IE6, 7 & 8 you can use the free dynaTrace AJAX Edition
You might actually want to check out the Developer tools that come with IE8. I know js debugging and profiling are part of it.
Take a look at YUI Profiler.
I need to debug JavaScript in Internet Explorer 7.
Unfortunately, its default debugger doesn't provide me with much information. It tells me the page that the error showed up on (not the specific script) and gives me a line number. I don't know if that is related to my problem.
It'd be nice if it could narrow down the error to a line number on a specific script (like Firebug can).
Is there an addon to debug JavaScript in IE7 like Firebug does in Firefox?
Thank you!
See also:
Does IE7 have a “developer mode” or plugin like Firefox/Chrome/Safari?
Web Development Helper is very good.
The IE Dev Toolbar is often helpful, but unfortunately doesn't do script debugging
The hard truth is: the only good debugger for IE is Visual Studio.
If you don't have money for the real deal, download free Visual Web Developer 2008 Express EditionVisual Web Developer 2010 Express Edition. While the former allows you to attach debugger to already running IE, the latter doesn't (at least previous versions I used didn't allow that). If this is still the case, the trick is to create a simple project with one empty web page, "run" it (it starts the browser), now navigate to whatever page you want to debug, and start debugging.
Microsoft gives away full Visual Studio on different events, usually with license restrictions, but they allow tinkering at home. Check their schedule and the list of freebies.
Another hint: try to debug your web application with other browsers first. I had a great success with Opera. Somehow Opera's emulation of IE and its bugs was pretty close, but the debugger is much better.
you might want to try
microsoft script debugger
it's pretty old but it's quite useful in the sense if you stumble on any javascript error, the debugger will popup to show you which line is messing up. it could get irrating sometimes when you do normal surfing, but you can turn if off.
here's a good startup on how to use this tool too.
HOW-TO: Debug JavaScript in Internet Explorer
I've found DebugBar.
Not as good as Firebug, but close.
In IE7, you can bring up firebug lite for the current page by pasting the following in the address bar:
javascript:var firebug=document.createElement('script');firebug.setAttribute('src','http://getfirebug.com/releases/lite/1.2/firebug-lite-compressed.js');document.body.appendChild(firebug);(function(){if(window.firebug.version){firebug.init();}else{setTimeout(arguments.callee);}})();void(firebug);
See http://getfirebug.com/lite.html.
Microsoft Script Editor is indeed an option, and of the ones I've tried one of the more stable ones -- the debugger in IE8 is great but for some reason whenever I start the Developer Tools it takes IE8 a while, sometimes up to a minute, to inspect my page's DOM tree. And afterwards it seems to want to do it on every page refresh which is a torture.
You can inspect contents of variables in Microsoft Script editor: if you poke around under Debug > Window you can turn on local variable inspection, watching etc.
The other option, Visual Web Dev, while bulky, works reasonably well. To set it up, do this (stolen from here):
Debugging should be turned on in IE. Go into Tools > Internet Options > Advanced and check that Disable Script Debugging (Internet Explorer) is unchecked and Display a notification about every script error is checked
Create a new empty web project inside of VWD
Right-click on the site in the Solutions Explorer on the top right, go to Browse With and make sure your default browser is set to IE (it's reasonable to assume if you're a web developer IE is not your default browser in which case that won't be the default.. by default)
Hit F5, IE will open up. Browse to the page you want to debug.
VWD will now open up any time you have a script error or if you set a breakpoint in one of the JS files. Debug away!
UPDATE: By the way, if you experience the same slowdowns as me with IE8's otherwise decent debugger, there is a workaround -- if you encounter or make IE encounter an error so that it pops up the "Do you want to debug" dialogue and hit Yes, the debugger will come up pretty much instantly. It seems like if you go "straight" into debugging mode the Dev Tools never inspect the DOM. It's only when you hit F12 that it does.
IE8 has much improved developer tools. Until then it's best to write javascript for firefox first and then debug IE using alert() statements.
Microsoft Script Editor can be used to debug Javascript in IE. It's less buggy than Microsoft Script Debugger but has the same basic functionality, which unfortunately is pretty much limited to stepping through execution. I can't seem to inspect variables or any handy stuff like that. Also, it only shipped with Office XP/2003 for some bizarre reason. More info here if you're game.
I downloaded the Visual Web Developer 2008 Express Edition mentioned by Eugene Lazutkin but haven't had a chance to try it yet. I'd recommend trying that before Script Editor/Debugger.
It's not a full debugger, but my DP_DEBUG extensions provides some (I think) usful functionality and they work in IE, Firefox and Opera (9+).
You can "dump" visual representations of complex JavaScript objects (even system objects), do simplified logging and timing. The component provides simple methods to enable or disable it so that you can leave the debugger in place for production work if you like.
DP_Debug
The IE9 developer tools worked for me. Just set the "Browser Mode" menu item to IE7.
Hey I came across the same problem and found this the application IETESTER. It's pretty awesome, it's an app that has IE 5.5,6, and 7 bundled into it. It doesn't matter what IE version you currently have. This allows you to have multiple versions side by side.
If you enable javascript debugging in IE options and have Visual Studio installed you can even debug the javascript in VS with all the debug options available to you(watches, conditional breakpoints ,etc.)
If you want to start debugging before an error occurs you simply have to put the line
debugger;
into your JS code and this bring you into VS to begin debugging after this statement.
This is absolutely amazing to me for testing backward compatibility for JS code.
Use Internet Explorer 8. Then Try the developer tool.. You can debug based on IE 7 also in compatibility mode
FireBug Lite:
http://getfirebug.com/firebuglite
The answer is simple.
Get Internet Explorer 9
Press F12 to load up Developer Tools
Switch the browser mode to IE7
Running your code through a Javascript static analysis tool like JSLint can catch some common IE7 errors, such as trailing commas in object definitions.
IE8 Developer Tools are able to switch to IE7 mode
If you still need to Debug IE 7, the emulation mode of IE 11 is working pretty well.
Go to menu: Dev Tools, then to emulation and set it.
It also gives error line information.
The following tools works great for me:
1) http://www.debugbar.com/
Provide a convenience UI to with feature like source, style, DOM, Script, HTML check. It also show the actual error in your JS file (which line, which file).
2) http://www.my-debugbar.com/wiki/CompanionJS/Installing
Provide a console for IE6 or IE7 ( which originally does not support)
Screenshot