incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon MacDonald <>
Subject Re: Performane in FileAPI
Date Sat, 22 Sep 2012 14:20:09 GMT
Here's my two cents. The current bridge in 2.0/2.1 is much slower than what
we are now defaulting to in the upcoming 2.2 release. That change improves
the FileReader performance greatly. However, switching to XHR speeds things
up by an order of magnitude. Using my quick patch the FileReader passes all
mobile spec test cases except the error conditions which need to be
converted. It looks like a major win for android if we make the switch.

Folks on other platforms should run your benchmark to see if there is a
similar improvement and then run my patch through mobile spec to see of
there are any failures.

With regards to CI yes we really do need this but I don't think we can set
it up in time to test this issue.

Going back to hacking the camera now and I'll get off my soapbox.


On Friday, September 21, 2012, Daniel Kurka wrote:

> Hello everyone,
> in several situations I got frustrated with the performance of the
> phonegap File API. For some time we have used XHR as a replacement for
> FileReader within phonegap apps.
> I would really like to see the IO performance of phonegap to improve.
> First step in that way might be to use XHR instead of the bridge.
> To get this started I talked with Brian at Phonegap Day EU and he decided
> the best way to do this is to actual get some data first, this is what
> CB-1478 is about.
> So far it seems that we can make a major improvement on Android, BB.
> (other still need testing though)
> As Filip already pointed out some kind of benchmark should go into CI, so
> that we will not regress at any point. What could I do about that?
> Simon already proposed a patch which might work, but I wanted to get some
> feedback on this first (
> )
> So what do you guys think what the best way forward is?
> -Daniel

Simon Mac Donald

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message