I'm using the standard PhoneGap plugin for writing to local files via HTML5. In the background my app is downloading data from a server and then saving it to disk as it comes in. Typical file sizes are around 20Mb.
If the user is scrolling the screen or some other UI action when writing is going on, my app will freeze for a second or two on an iPad 2 running iOS7. The file writing operation is wrapped in a setTimeout call (so it doesn't block the main thread) but this doesn't seem to help.
The XCode console reports this while file writing is going on (the lag feels like it happens for about a second or 2 and not the 200ms implied here):
THREAD WARNING: ['File'] took '93.378906' ms. Plugin should use a background thread.
THREAD WARNING: ['File'] took '125.793945' ms. Plugin should use a background thread.
What can I do to avoid the lag? How can I diagnose where the lag is happening?
Wrapping up the file writing operations with setTimeout does not prevent the main thread from getting blocked, where did you get that? It just delays the execution of the wrapped function, which in your case doesn't help you at all.
Nevertheless, I don't even think this is your real problem, because the file plugin's write operation is already wrapped up for execution in a background thread, which tells you the linked line from the iOS plugin source code.
My guess is there is some other stuff happening, that blocks your UI thread. Which functions from the plugin are you calling exactly? Try to debug/profile the whole process, when the UI lag occurrs, for example in Safari Remote Debugger.
If that doesn't help you, you should post more specific code which could give some hints about what is happening and what the problem could be.
Related
First some backstory:
We have a website that includes a Google Map in the usual way:
<script src="https://maps.googleapis.com/maps/api/js?v=....></script>
Then there is some of our javascript code that initializes the map. Now suddenly yesterday pages started to load but then freezed up entirely. In Chrome this resulted in having to force quit and restart. Firefox was smarter and allowed the user to stop script execution.
Now after some debugging, I found out that a previous developer had included the experimental version of the Google Maps API:
https://maps.googleapis.com/maps/api/js?v=3.exp
So it's likely that something has changed on Google's servers (which is completely understandable). This has uncovered a bug on our end, and both in combination caused the script to hang and freeze up the website and the browser.
Now ok, bug is found and fixed, no big harm done.
And now the actual question:
Is it possible to somehow sandbox these external script references so that they cannot crash my main site. I am loading a decent amount of external javascript files (tracking, analytics, maps, social) from their own servers.
However such code could change at all times and could have bugs that freeze my site. How can I protect my site? Is there a way to maybe define maximum allowable execution time?
I'm open to all kinds of suggestions.
It actually doesn't matter where the scripts are coming from - whether an external source or your own server. Either way they are run in the clients browser. And that makes it quite difficult to achieve your desired sandbox behavior.
You can get a sandbox inside your DOM with the usage of iframes and the keyword "sandbox". This way the content of this iframe is independent from the DOM of your actual website and you can include scripts independent as well. But this is beneficial mainly for security. I am not sure how it would result regarding the overall stability when one script has a bug like an endless loop or similar. But imho this is worth a try.
For further explanation see: https://www.html5rocks.com/en/tutorials/security/sandboxed-iframes/
I have a problem with cordova 4.2 while using Xcode 7.0.1,when I run my application on IOS9 ,loading JS files taking around 25 seconds which is very bad comparing to android.
I tried to detect the problem by putting flag ,the loading is stuck with getting the handlebars (Since I am using Ember js).
I tried to minify the hbs with no improving.
function onDeviceReady() {
Helpers.getScript('app/app.js');
Helpers.getScript('app/helpers.js');
Helpers.getScript('app/init.js');
Helpers.getScript('app/router.js');
}
Thanks in advance
Okay. If all you are doing is loading files, then there is no need to delay loading those files. The only time you want to delay loading a file *is* if you have some active code in those files.
To be clear, there are some libraries that load and become active as soon as they are loaded. Those libraries would set variables or access the system in some way. These types of libraries need to be loaded AFTER the deviceready event. Otherwise, you are free to load libraries as soon as you can, and even before the deviceready event.
On your App, I cannot say why it is delaying to start. You say 20+ seconds, and I can only think it might be the delayed library loading.
NOTE: not all apps are built the same. This means that on Android, there are libraries that come with the system, and there are libraries that Cordova adds. It might, (might be) that you are loading a larger APP on an iOS system, and that might be the delay.
In any case, let me know what you have tries, and what worked and what did not.
One of my users is intermittently getting a dialog in IE 8 that says:
A script on this page is causing Internet Explorer to run slowly
This problem has been reported numerous times in the MSDN forums and other places on the web. For example:
http://social.msdn.microsoft.com/Forums/ie/en-US/0fdb7550-0a59-4553-a90e-1958475f2ce5/how-to-debug-a-script-on-this-page-is-causing-internet-explorer-to-run-slowly?forum=iewebdevelopment
http://social.msdn.microsoft.com/Forums/ie/en-US/dafffdd8-a390-4a3c-a904-867acaec298e/error-message-a-script-on-this-page-is-causing-internet-explorer-to-run-slowly-for-ie8?forum=whatforum
http://social.msdn.microsoft.com/Forums/ie/en-US/e9d16d2a-60e1-4d6f-8f80-0d981eab3a2e/a-script-on-this-page-is-causing-your-web-browser-to-run-slowly?forum=bingmapsajax
So, this question is a duplicate of those and many others. But it is an intentional duplicate, because I don't think any of those questions were answered in a way that helps a user (developer) to determine precisely what in his scenario causes the dialog to appear.
I know that based on this page:
http://support.microsoft.com/kb/175500
the dialog appears when a certain number of statements have executed since a new script begins execution (through a variety of means). By default the number of statements is 5,000,000 but this is configurable via a registry entry.
The general prescription to this problem is a combination of:
Write less code. Unfortunately, this is not always possible.
Use web workers. This is not an option for IE before IE 10, nor with
some mobile browsers.
Use setTimeOut, setInterval, event handlers, etc to break the
script(s) up. This is a legitimate strategy across all browsers.
So, I understand what the problem is in general terms, and I understand what the options are to solve the problem, again in general terms. The question is, how to determine what area(s) of the code are causing the dialog to appear for a specific user? Often this problem occurs with a very large code base (including third party libraries), so a manual review of the code base without some tooling support is not feasible.
Most browsers, including IE8 and later, have profiling tools that enable the developer to determine JavaScript CPU usage. With the exception of IE, other browsers decide a script is long running not based on the numbers of statements executed but rather the amount of time the script spent executing. To this end, the profilers available in (or as add ons) to the browsers can identify the percentage and usually raw time spent executing a function, both inclusively and exclusively for a function, and the results can be sorted accordingly. IE's profiler will also give you a count of how often a function is called. None of these profilers tell you how many statements of code within a function were executed during profiling; they tell you only how long was spent in the function and how many times the function was called. This doesn't help with IE's slow script dialog logic, which is based on the number of statements (not time) that were executed. There is sometimes a correlation between the time spent executing a function and the number of statements, but it is not a reliable relationship as of course different types of statements can take very different lengths of times to execute (e.g. many native JavaScript functions are faster than calls which update the DOM; both have the same statement count but the former executes faster than the latter, making examining %/raw time not very useful).
One approach I've used that is of some value is when the slow script dialog appears, start the debugger in IE (if not already started) and select the break on next statement command in the debugger. Then click the dialog button in the browser that allows the slow script to continue executing. At this point, the debugger is invoked and the developer can examine the call stack to determine what is executing at the time the slow script dialog appears. This is okay, but a very manual approach and there's no guarantee there aren't multiple scripts running that can at different times invoke the dialog.
An interesting idea I've seen suggested is to use a JavaScript code coverage tool to instrument the code base. There are multiple JavaScript code coverage options out there, but the ease of use of a browser extension that could dynamically instrument the code seems like an ideal solution. (Another interesting idea is to use a proxy server, for example http://siliconforks.com/jscoverage/manual.html; 'jscoverage --server --proxy', but I couldn't get this to work on virtually any website, except the the silicon forks website itself). There's a proof of concept one available for Chrome (http://googletesting.blogspot.ca/2011/10/scriptcover-makes-javascript-coverage.html) that I think could be a great start for helping resolve the the slow script problem -- if such an extension could be made for IE.
So, to reiterate my main question is what tools/processes can one use to debug/analyze a slow script dialog appearing on a user's machine? A subquestion would be, does anyone know of any JavaScript code analysis tools that could be repurposed to help in diagnosing the slow script dialog in IE, and that takes minimal deployment effort? Can an IE extension be written, in theory, that does the sort of code coverage as the Google' script cover extension does?
Thank you,
Notre
In the old times JavaScript was not used that much. Pages used to me more static. These days the PC's were less powered and it was more popular to run complex tasks on the server. JavaScript was only used for some animations.
Microsoft (my way or no way) took their time to acknowledge heavily JavaScript-ed content. (They were also fiddling with their JScript in IE8). Until IE9 they were considering that running > 5 000 000 instruction in a script is a potential mistake.
I'm not aware of any tool that retrieves the instructions count. It's a browser build in feature.
But most of the browsers retrieve the execution time of a function. I know that in every different computer, same number of instructions can take different times, but you can set a benchmark.
Run a script with 5 000 000 instructions on the machine and see how long it takes to run. Then use that time to benchmark your other JavaScript. It's not 100 % accurate but it can became close once you fiddle with it.
Since old IE developer tools are quite poor you can use some third party one. A ussage example here:
deep-tracing-of-internet-explorer
Anyway, the “A script on this page is causing your computer to run slow ...” is only a problem in IE4 - IE8. Since those browsers are obsolete, so should this question be.
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
Recently I have been having issues with Firefox 3 on Ubuntu Hardy Heron.
I will click on a link and it will hang for a while. I don't know if its a bug in Firefox 3 or a page running too much client side JavaScript, but I would like to try and debug it a bit.
So, my question is "is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?"
I would like to be able to see what tabs are using what percent of my processor via the JavaScript on that page (or anything in the page that is causing CPU/memory usage).
Does anybody know of a plugin that does this, or something similar? Has anyone else done this kind of inspection another way?
I know about FireBug, but I can't imagine how I would use it to finger which tab is using a lot of resources.
Any suggestions or insights?
It's probably the awesome firefox3 fsync "bug", which is a giant pile of fail.
In summary
Firefox3 saves its bookmarks and history in an SQLite database
Every time you load a page it writes to this database several times
SQLite cares deeply that you don't lose your bookmarks, so each time it writes, instructs the kernel to flush it's database file to disk and ensure that it's fully written
Many variants of linux, when told to flush like that, flush EVERY FILE. This may take up to a minute or more if you have background tasks doing any kind of disk intensive stuff.
The kernel makes firefox wait while this flush happens, which locks up the UI.
So, my question is, is there a way to have some kind of process explorer, or task manager sort of thing for Firefox 3?
Because of the way Firefox is built this is not possible at the moment. But the new Internet Explorer 8 Beta 2 and the just announced Google Chrome browser are heading in that direction, so I suppose Firefox will be heading there too.
Here is a post ( Google Chrome Process Manager ),by John Resig from Mozilla and jQuery fame on the subject.
There's a thorough discussion of this that explains all of the fsync related problems that affected pre-3.0 versions of FF. In general, I have not seen the behaviour since then either, and really it shouldn't be a problem at all if your system isn't also doing IO intensive tasks. Firebug/Venkman make for nice debuggers, but they would be painful for figuring out these kinds of problems for someone else's code, IMO.
I also wish that there was an easy way to look at CPU utilization in Firefox by tab, though, as I often find myself with FF eating 100% CPU, but no clue which part is causing the problem.
XUL Profiler is an awesome extension that can point out extensions and client side JS gone bananas CPU-wise. It does not work on a per-tab basis, but per-script (or so). You can normally relate those .js scripts to your tabs or extensions by hand.
It is also worth mentioning that Google Chrome has built-in a really good task manager that gives memory and CPU usage per tab, extension and plugin.
[XUL Profiler] is a Javascript profiler. It
shows elapsed time in each method as a
graph, as well as browser canvas zones
redraws to help track down consuming
CPU chunks of code.
Traces all JS calls and paint events
in XUL and pages context. Builds an
animation showing dynamically the
canvas zones being redrawn.
As of FF 3.6.10 it is not up to date in that it is not marked as compatible anymore. But it still works and you can override the incompatibility with the equally awesome MR Tech Toolkit extension.
There's no "process explorer" kind of tool for Firefox; but there's https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Venkman with profiling mode, which you could use to see the time spent by chrome (meaning non-content, that is not web-page) scripts.
From what I've read about it, DTrace might also be useful for this sort of thing, but it requires creating a custom build and possibly adding additional probes to the source. I haven't played with it myself yet.