Develop Reference

How to debug Javascript process and animation?

There are lots of tools for debugging JavaScript codes (like FireBug, Chrome console), but is there a tool for debugging a process. This probably need to monitor the resource (e.g. CPU) usage to find the bottleneck in the process.
I create Javascript animations for moving an element (in a simpler case opening/closing menu), but the movement is now smooth. Different factors can cause overload, e.g. heavy CSS3 gradients. But how to detect the rate-limiting process?
This is indeed the problem of most of websites. When opening a webpage, overload of javascript processes kills the page load. Most of animations/menu actions are broken.
When a JavaScript animation is not running smooth, how do you debug the problem?
OR a more general question, how to monitor the resource usage of running JS process to make a webpage lighter (an faster load on computers with limited resources)?

I would use the timeline->frames in Chrome. Paul Irish has a lot of great talks about this, here is one https://www.youtube.com/watch?v=Vp524yo0p44
Also when doing animation do not use setTimeout/setInterval, the precision is not good enough. Instead use requestAnimationFrame. More information about requestAnimationFrame can be found here. http://paulirish.com/2011/requestanimationframe-for-smart-animating/
Edit: This talk by Paul is also really interesting regarding speed and debugging speed in the browser: https://www.youtube.com/watch?v=MllBwuHbWMY, and here is a quite recent discussing 2D transforms vs absolute positioning: https://www.youtube.com/watch?v=NZelrwd_iRs

Different machines => different performance => different bottlenecks
If animation isn't running smoothly I try to lower on graphics or animation itself. Who says that users are using as powerful machines as you do? So they may hit the issue sooner than you.
But I'd still suggest Process Explorer as it can individually show load of a particular processes. In general it's a more insightful tool compared to default Task Manager provided by Windows.

Android performance hit on later versions than 2.3.5 (phonegap/cordova)

Currently I'm developing an Android App with Phonegap/Cordova (2.1.0/2.2.0) , JQ-Mobi(not jQueryMobile), HTML5 and Javascript and CSS3. The App contains 2 native exstensions.
Somehow, when I export my project to a device with the lastest Android version, the app runs so much slower than an 2.3.5 device.
I've tried enabling the HardwareAcceleration and removed all of the box-shadows and other tough to render css3 stuff. Still on a 4.1.1 or 4.0.4 it runs crappy.
I also upgraded to the latest version of Cordova (now 2.2.0) and it doesn't seem to make it better.
Javascript DOM manipulation happens for about 80-90% when the app is started.
The worst performance is in switching panels and scrolling through forms, most of them have some transitions in them.
I tested it on a Samsung Galaxy S2 android 2.3.5 and it look fine and performs well.
Same device, but 4.0.4 runs crappy.
Samsung Galaxy S3 4.1.1 runs even crappier.
HTC Flyer P512 with android 3.2.1 runs it how it should be running.
Can anyone help me out here? How do I get this performance up? Any Hint or Tips which I havn't mentioned?
I'd like to add that I don't get the issues on an Iphone 3gs and up to explain that it is definitly an Android problem.

My phonegap apps run smoothly on iOS, but perform extremely poorly on Android. As I understand it this is just because Android is much slower at interpreting JavaScript than iOS.
One thing that can help a lot is cutting down on the use of libraries such as jQuery and JQM. If you want to include them, don't use them where you don't have to.
functions such as jQuery.animate run notoriously slow on Android and you'd be better of iterating over arrays with raw JS rather than using jQuery.each etc. etc.
The problem is not just with graphical rendering, but with the speed at which JavaScript is executed. Although lowering the screen resolution can boost your performance.
Edit
I am trying to get to the bottom of this myself and the only answer I can get is to keep computational operations at a minimal.
Use libraries sparingly and solve your problems with raw and well written JavaScript when possible
Keep a small DOM and manipulate it as seldom as possible
Make use of JavaScript performance enhancing techniques
So it really seems that this is a core performance issue, rather than something that could be solved on the Phonegap layer. As a non-scientific example, the exact same init() function on one of my apps executes in about 1.2 seconds in iPhone 4s on average, while taking a sluggish 5 seconds to complete on my samsung galaxy s3.

The core of the problem is that everything is loaded and running in a single page (execution context), personally, though single page apps (sencha, jqmobile etc) are all the rage, the performance on modern devices does not do the user experience any justice. I would separate the app into different pages, this will significantly reduce the size of the DOM and create separate execution contexts for each new page, meaning that your main page (execution context) is nice and lean (DOM is small).

I had the exact same problem. I asked a similar question and eventually answered it myself here after a tonne of research:
Cordova/Phonegap slow performance with Open Layers on new Tablet, but fine on new phone
I won't repeat the entire answer I gave, but the slow performance on certain Android versions is due to what is essentially a bug in WebView which throttles the CPU support for GPU based processes, but doesn't provide GPU support to compensate.
Kitkat V4.4.3 upwards have this fixed, but older versions such as V4.4.2 which are still being used on some devices still suffer.
You can avoid this by not using WebView at all for the HTML rendering, and instead use Crosswalk. For our project this solved the problem entirely and we now have a smooth running application across all Android versions we're targeting. It's quite trivial to do as well.
https://crosswalk-project.org/documentation/cordova.html
https://blog.nraboy.com/2014/10/use-crosswalk-ionic-framework-android-apps/

Try using multithreading and background processing for resource extensive operations.
That worked for me when i had similar problem with one of my apps when it crashes when it runs on versions later than 2.3.3. I never worked with PhoneGap so I'm not sure how you are going to do it.

Why does Javascript run so slow on iPhone?

I've been researching writing an app for iPhone. I really like the look of PhoneGap which basically allows you to contain a webpage in an app. My skills are primarially in HTML/Javascript so this tool allows me to make the most of my skills without having to spend many hours learning how to write an app natively for the iPhone.
I've been doing some tests on my iPhone for Javascript, and some seemingly simple examples run painfully slow. Really slow. This unfortunatly is a big problem for my task!
Any work arounds? If I want to do anything interesting am I going to have to write a 'proper' app?
An explanation on why Apple have seemingly created such a bad implementation of Javascript would be interesting as well (possibly to make more money? Less web apps = more apps in the store?)
References
http://ajaxian.com/archives/ipad-javascript-shockingly-slow

Javascript is not particularly slow, but the DOM is very slow.
I think it is the same as a desktop browser, but magnified.
I would check first all DOM manipulations, if they can't be optimized.
Another option, is to use a templating engine.The main DOM manipulations are done through innerHTML injection, which is fast even on mobiles.
We've built a mobile version of our web app, and we use PURE (an open source JS lib we created) to render the HTML from JSON data, and it is very responsive.
We went the HTML5 way(not native) but I think generating the HTML could be done the same way when wrapped in PhoneGap.

I don't think Apple has created any special implementation of Javascript for Mobile Safari. Probably it's the same as or very similar to the desktop Safari.
These devices are small and have strict power constraints, so the CPU is slow.

Apparently iOS won't do JIT compilation of JavaScript (unlike Android) due to a security feature: http://daringfireball.net/linked/2010/07/22/android-ios-js-benchmarks
Good point about DOM access being the issue though: I don't know how much these benchmarks test DOM operations.

#Rudiger: Just a thought - A lot of the improvements to desktop computer speed since "8 years ago" have been attained in part through the use of multiple processors. Javascript is single-threaded, and so presumably would not be able to take advantage of such multiple processors. Yes, I know that browsers can take advantage of it, and that putting the other stuff on the other processors can provide more CPU power to the Javascript thread, but I have an app that is mostly raw Javscript internal processing, where the main thing that is going on is search and array manipulation.
So, when comparing desktop power to mobile processor power, for my purposes, maybe the slowdown would not be so bad? I currently run at very acceptable speeds on Safari on a six-year-old notebook computer with a single processor. So I'm thinking that Safari on iPhone or iPad for me might not be that much worse. Do you think this is reasonable?

Actually, I think Apple has a vested interest in keeping javascript out of the Iphone as much as possible.. they seem to want to regulate things through their appstore by requiring applications that run natively.. I'm curious if javascript is also slow on Android phones, (I've never used one before).. if its not then I think it is a bit strange that the Iphone would be slow with javascript, at any rate, they are already losing market share and will have to address the issue at some point I am sure, I think people are catching on to Apple's games and idiocy in trying to micromanage everything now that more legitimate alternatives are coming out in the mobile device space.

Javascript Speed - Chrome v Firefox

I wrote this small game at http://amarnus.me/games/dodge. Now if you trying playing the game in both Firefox and Chrome, you would clearly notice that it is significantly slower in Firefox. You can call it an unintentional cheat code, yes. ;-)
So my question is - Is this because of a slower Javascript engine in Firefox when compared to Chrome's? Or does it have something to do with bad coding? (In my defence, I am a Javascript newb)
Assuming that it is the former, then is this not a point against (disadvantage of) HTML5 games? (The ones using the <canvas> tag like mine)

Firefox is slower than chrome in javascript. However, I believe that it's also slower using the canvas-tag. This will probably improve with ff4 (have you tried the beta?).
There is also a nes emulator out on the web somewhere using js and canvas, and it runs in about 30fps on chrome (if I remember about correctly), but only about 10 in ff.
Time is probably your best friend :-P, though you can alwasy try to optimize.
I believe that browser-games will come in time, but it's not ready as of yet to anything too advanced. Maybe about the time ie12 comes out :-P.
[Edit]
Btw: I tried the game in FF4b1, and I thought it ran great. Probably not as fast as in chrome, but not far from it :).

In order to get help you might consider providing a non-minified version of your script.
I see that there are 8ms setIntervals in your code. As mentioned above, Firefox never goes below 10 ms (yet). Playing your game in FFox 4 it is very enjoyable, though. I saw two very small hickups that clearly were caused by garbage collection. Chrome has an edge over the Fox in that regard. Even though SpiderMonkey (that handles GC in Firefox) has improved dramatically from 3.5 to 3.6 it's still not good enough for many games. In 4.0 it is a lot better, but still not quite as good as in Chrome or Opera. (It is being worked on.)
Playing the game and looking briefly at your code, I see no complexity that would cause Firefox not to be able to handle what's going on. Also Firefox 4 has hardware accelerated Canvas that is marginally faster than IE9 and a lot faster than Chrome.
There is a notion on the web that Chrome is faster than Gecko when it comes to canvas, but that is because people rarely profile their pages. In fact, canvas in Firefox 3.6 is already at least as fast as in Chrome, but many tests don't show it since the JavaScript is slower. (And some JavaScript tests are slower because Firefox does not handle the test harness well.)
All this leads to lots of confusion and misinformation. The bottom line is that your game should be OK in Firefox 4. You should see if there is anything you can do to avoid triggering unnecessary GC. E.g. are you re-using variables or creating unnecessary new ones?
However, in Opera 10.53 it was not enjoyable. Not because Opera could not keep up with the speed, but since instead of moving the bottom piece, it was kept stationary and the whole playing field moved instead. (I managed to go to level 17 in my first try in spite of this.) In Opera 10.6 the page fails to load properly.
You probably need to debug your code - or perhaps file a bug with Opera if it's a regression. (I'll tweet this to get their attention.)

I'd blame a large part of it on setTimeout and setInterval having a ~10ms minimum in browsers such as IE and Firefox. This was originally adopted to stop pages from consuming the entire CPU should they naively use 0ms to run as fast as possible. Chrome launched without a limit but is now moving to a 4ms minimum to match the recommendation in HTML5.
John Resig has some awesome posts investigating setTimeout limits and accuracy.
Mozilla browsers can actually tell you how late (or early!) they're running with each setInterval call. Check out the MDC setTimeout article (google "mdc settimeout" and check out the grey note in the syntax section).
Apart from timer problems, Firefox is just generally slower in JS execution (for now at least) and it feels as if Skia (Chrome's graphics lib) is just faster at rasterising too.
Hope this helps :)
(I originally had a bunch of useful links here, but it's my first post and the spam filter slapped me down.)

jQuery animate does something similar to your DOM object movement.
I would look into their code and see how they do the actual movement, it's probably the most efficient way since it's built in jQuery.

Chrome is designed to have a faster Javascript engine.
I don't think it says anything about HTML5 games. You will always find users with faster or slower setups than others, be it hardware, software or a user's personal habit of keeping many applications running at once. If your game were written in Flash or Java, then a user with slower hardware would see a similar slowdown.
You may be able to make changes to your code in order to speed it up. I haven't examined it in great detail, but I see you have constructs like if(dodge.goRight == true .... Although not a source of slowness, this does hint that you may not have used the optimal solution everywhere.

You can test your browser javascript engine with IE site.
http://ie.microsoft.com/testdrive/
They assert to the highest speed javascript engine they have with IE9

Try out this technique: setTimeout with a shorter delay
Let me know if it helps. I'm kinda curious now. :)
Good luck!

Does Silverlight have a performance advantage over JavaScript?

At a recent discussion on Silverlight the advantage of speed was brought up. The argument for Silverlight was that it performed better in the browser than Javascript because it is compiled (and managed) code.
It was then stated that this advantage only applies to IE because IE interprets Javascript which is inefficient when compared to that of other browsers such as Chrome and FireFox which compile Javascript to machine code before execution and as such perform as well as Silverlight.
Does anybody have a definitive answer to this performance question. i.e. Do/will Silverlight and Javascript have comparable performance on Chrome and Firefox?

Speculating is fun. Or we could actually try a test or two...
That Silverlight vs. Javascript chess sample has been updated for Silverlight 2. When I run it, C# averages 420,000 nodes per second vs. Javascript at 23,000 nodes per second. I'm running the dev branch of Google Chrome (v. 0.4.154.25). That's still almost an 18x speed advantage for Silverlight.
Primes calculation shows a 3x advantage for Silverlight: calculating 1,000,000 primes in Javascript takes 3.7 seconds, in Silverlight takes 1.2 seconds.
So I think that for calculation, there's still a pretty strong advantage for Silverlight, and my gut feel is that it's likely to stay that way. Both sides will continue to optimize, but there are some limits to what you can optimize in a dynamic language.
Silverlight doesn't (yet) have an advantage when it comes to animation. For instance, the Bubblemark test shows Javascript running at 170 fps, and Silverlight running at 100 fps. I think we can expect to see that change when Silverlight 3 comes out, since it will include GPU support.

Javascript is ran in a virtual machine by most browsers. However, Javascript is still a funky language, and even a "fast" virtual machine like V8 is incredibly slow by modern standards.
I'd expect the CLR to be faster.

I'd say that architecturally, it's a wash.
On the one hand Silverlight is MSIL code, which is reasonably fast compared to raw, optimized native code but still runs slower due to the VM (CLR) overhead and will still have slow initial load times when being ngen'd.
On the other hand the speed of Javascript is much less reliable due to the huge variations in Javascript engines which have an order of magnitude, or more, range in performance. You have slow interpreters like IE, though IE8 is speeding things up, and then you have faster compilers/interpreters like SpiderMonkey and V8 which have only recently begun to explore the performance limits of Javascript. There's also new technologies in the R&D phase like TraceMonkey which have tremendous potential to vastly improve Javascript performance (getting close to native code speeds). Javascript does have the inherent disadvantage that it is single-threaded, but given the difficulty of writing good threaded code it's hard to say how much difference that makes.
At the end of the day when comparing apples to apples the real performance bottleneck is the DOM, and there it doesn't much matter what technology you're using to manipulate it.

I don't understand why you're trying to compare a scripting language with a browser plug-in.
They don't do the same thing. The former interacts with the DOM while the latter runs multimedia apps inside the browser.
Comparing Flash and Silverlight from a performance point of view would seem more useful to me.
EDIT: After some research I found out that you can interact with the DOM in Silverlight. I don't think it can be seen as a good Javascript replacement though, performance concerns aside, unless you have some heavy client-side interaction needed. I see two main disavantadges :
1) You will force your users to download a Silverlight app instead of relying on a relatively small .js file.
2) Your users are required to install Silverlight before using your page.

From the cursory testing I've done, Silverlight runs faster.
Here are some intersting results I gathered from http://bubblemark.com/
In general, Silverlight was much faster, but Chrome's javascript implementation tore everyone else to bits!
Keep in mind, this is only on one machine, one os (XP) etc. you would need to do much more extensive tests to achieve more.

I'd say yes, since it has .NET's CLR. At that, with resent developments in JavaScript implemented in Google Chrome and in the yet to be fully released Firefox 3.1, one may want do do some benchmarking of their own; I don't know of any comparisons as yet. (anyone?)
Nonetheless, in my opinion, .NET should be generally faster than Javascript, and as has been noted before, this will not speed up the network. Consequently for complex algorithms, SilverLight will be faster, but for network requests, you may not have any noticeable difference.
On the performance question, you may want to have a look at Flash 10 which can allow c/c++ code using "Alchemy". This may be a more portable solution than SilverLight.

It looks like that Chrome's javascript implementation is faster than Silverlight

Platforms should be considered here. How Silverlight performs in Lnux or Solaris or Mac is really big question !

How abt HTML5 .I think while comparing the performance of javascript HTMl plays a serious role. So we shoul definitely compare the performance using HTML5 + javascript and Silverlight .

Sre, if you're using "Internet Exploder" it probably will...
If you're using V8 (Chrome) or the upcoming Safari and FireFox, I seriously doubt it ;)
I would love to see that Chess thn BTW where IE is playing using Silverlight and Chrome is using Javascript. THAT would rock MSFT...!! ;)