Huge speed problem on iPad (perf of "fnCallback")...

tommck

I am using DataTables 1.8.1 (tried 1.8.2.nightly as well) with the Scroller plugin. When I load data, it is grabbing 39 rows of data (total of 9 columns) from the server (using bServerSide=true and ajax).

On Desktop Safari, the call to fnCallback takes, on average, about 250ms. On iPad Safari, it takes approximately 3000ms.

Is there anything obvious or simple that could be going on that would cause this kind of speed problem on the iPad? I know the browser is different and slower, but I didn't expect a > 10 times difference running DataTables functions there.

Any help would be _greatly_ appreciated!

allan

Wow - that really is super slow! 3 seconds to do the draw callback?! All the callback does when using Scroller is position the table and set the height of the forcing element - I'd be amazed if that took 3 seconds. Is there a Javascript profiler on the iPad that could say a little more specifically what is taking up the time. Otherwise it might be a case of putting in some "new Date()" debug statements.

Allan

tommck

The "new Date()" statements is how I timed it :)

I don't know of any other profilers...

tommck

I remember seeing somewhere on the Forums that you make some "eval" versus other methods choices based on browsers. Is there anything like that in the redraw code that I might tweak to see if it is the problem?

fbas

http://www.apple.com/safari/features.html

[quote]
JavaScript Profiler
Optimize your JavaScript code using the state-of-the-art JavaScript Profiler in the Profiles pane. The Profiler lists the performance characteristics of each of your script’s functions, making it easy to pinpoint problem areas and drill down to the offending lines of code.[/quote]

Ipad's Safari has a profiler. Safari is WebKit (hey! DataTables example tables came in handy!) and probably has same/similar debugger as Chrome.

tommck

That is referring to the desktop Safari browser. You do not have access to anything but the Console output on the iPad. I already put a method in to proxy debugging messages to my server from the iPad so I can see the debug output...

fbas

oh :| sorry. maybe this? YUI js-only profile library.

http://stackoverflow.com/questions/6160073/profile-javascript-on-ios

tommck

looks like the "scrolling" draw callback (_fnSCrollDraw) is taking ~ 1000ms
Also, the loop to draw the rows inside _fnDraw is taking ~1400ms

I'll dig in more

tommck

So, from the fnScrollDraw stuff, here are the outliers...

1) the if/else block starting with "if (o.oScroll.sX === "") takes 231ms
2) the if block starting with "if (o.nTFoot !== null)" takes 297ms
3) The block starting with the comment "Recalculate the sanity width " and ending with "$(anHeadSizers).height(0);" takes 316ms

tommck

Inside the row drawing logic,

"_fnCreateTr" logic took 930ms
"_rowCallbacks" took 398ms (I know this is my logic)

tommck

Keep in mind that this is only 39 rows of data!

tommck

So, anybody have any ideas on this?

It's pretty much a show stopper for code that should already have been in production at this point. I'd really appreciate any hints/help I can get

fbas

sorry, i have 0 experience on, or access to, iPad.

is there a "virtual" iPad you can test on, that gives you more info on system internals and debugging/profiling?

tommck

unfortunately, there's only a really crappy emulator that only runs on Macs. Doesn't help.

beltrachi

Hey Tommck, how did you solve this?

I'm having issues with Ipad perfomance too and the measures i get are really akward.

Thanks

GregP

We would like to be more responsive on the iPad as well, so any information anyone has would be appreciated on this end, too.

I'm willing to believe it's really up to Apple to come up with something that performs better, but in the meantime a snappier application is a better one. ;-)

beltrachi

In my case I found the reason. It was my CSS.

I found the answer in http://mir.aculo.us/2010/06/04/making-an-ipad-html5-app-making-it-really-fast/

My solution has been this one: https://github.com/gnuine/ubiquo_core/commit/37287fb77ae779d1ddb250add0a0b60ca73c73ab

Good luck!

tommck

Been working on it. When I get in front of a PC, I'll try to write up what I know so far..

T

tommck

Generally, I have noticed that the speed on the iPad is mostly due to non-DataTables stuff. The browser does not have a huge memory cache and the process is way slower than PCs.

So, basically, it's pure web dev optimization like:
* Favor single jQuery delegate() calls to binding events in the fnRowCallback or something like that
* Cache images if you can. (Make sure your server-side code is set up for far-future caching of any images you can).
* Minify/combine JS, etc

GregP

Great, thanks for reporting back, Tom, and also beltrachi for the CSS tips and links. Gives me something to start on for snappier iPad performance.

tommck

No problem. I am also almost done with a tweaked version of Allan's Scroller Plugin that uses Matteo Spinelli's iScroll-4 script to allow on finger scrolling with acceleration, momentum, etc. It's pretty sweet, actually... :)

When it's done, Allan said he'd post it here in "Extras"