On 2014-04-30, 10:58 AM, David Rajchenbach-Teller wrote:
2. Performance: OS.File's performance on b2g was apparently worse than
the XPCOM I/O function, it seems. I'm curious to know which device you
ran the benchmarks on, and what the benchmarks actually tested. It
could be that those performan
On Wed, Apr 30, 2014 at 6:14 AM, Henri Sivonen wrote:
> As far as I know, there are two issues with XHR when it comes to local
> file input:
> 1) It wants a URL instead of an nsIFile and nsIFile doesn't have a
> getter for a URL pointing to the same file, so there's a mismatch
> between what you
On 30/04/14 16:48, Ehsan Akhgari wrote:
> 1. OS.File uses a JS ChromeWorker which requires an unacceptable amount
> of memory on b2g, on Tarako specifically.
True.
> 2. Performance: OS.File's performance on b2g was apparently worse than
> the XPCOM I/O function, it seems. I'm curious to know whi
On 2014-04-30, 9:41 AM, David Rajchenbach-Teller wrote:
On 30/04/14 15:40, Gavin Sharp wrote:
I thought the "performance problems" in question were related to memory
use/worker initialization. But
https://bugzilla.mozilla.org/show_bug.cgi?id=981085#c0 doesn't really
have any useful detail.
Ehsa
On 30/04/14 15:40, Gavin Sharp wrote:
> I thought the "performance problems" in question were related to memory
> use/worker initialization. But
> https://bugzilla.mozilla.org/show_bug.cgi?id=981085#c0 doesn't really
> have any useful detail.
>
> Ehsan, what needs were you referring to there, and
I thought the "performance problems" in question were related to memory
use/worker initialization. But
https://bugzilla.mozilla.org/show_bug.cgi?id=981085#c0 doesn't really have
any useful detail.
Ehsan, what needs were you referring to there, and are they tracked in bugs?
Gavin
On Wed, Apr 30,
I don't know of any performance problems for reading files with OS.File
at the moment. Actually, I benchmarked it and we are 2x-5x faster than
NetUtil at reading + decoding files, these days.
Cheers,
David
On 29/04/14 17:22, Nathan Froyd wrote:
> - Original Message -
>> The current best
On Tue, Apr 29, 2014 at 6:27 PM, Gavin Sharp wrote:
> Ah right, I had forgotten about those issues. That's in fact exactly the
> code that Henri was looking at. XHR would perhaps be better than the XPCOM
> IO if it works, but I don't think anyone's done that investigation.
As far as I know, there
Ah right, I had forgotten about those issues. That's in fact exactly the
code that Henri was looking at. XHR would perhaps be better than the XPCOM
IO if it works, but I don't think anyone's done that investigation.
Gavin
On Tue, Apr 29, 2014 at 11:22 AM, Nathan Froyd wrote:
> - Original M
- Original Message -
> The current best practice for file I/O in privileged JS is OS.File. It
> has mechanisms for doing encoding conversion and compressing data.
> That there is some b2g code using NetUtil/XPCOM instead is a bug, and
> probably was caused by the relevant code being written
The current best practice for file I/O in privileged JS is OS.File. It
has mechanisms for doing encoding conversion and compressing data.
That there is some b2g code using NetUtil/XPCOM instead is a bug, and
probably was caused by the relevant code being written prior to the
existence of OS.File (o
On Tue, Apr 29, 2014 at 12:12 PM, Henri Sivonen wrote:
> The Web API for doing I/O is XHR, which would also take care of
> encoding conversion.
So it turns out that NetUtil.readInputStreamToString() *could* perform
the encoding conversion, too. Yet, callers opt not to do so and
perform conversion
> The Web API for doing I/O is XHR, which would also take care of
> encoding conversion.
...and JSON parsing. I see hand-rolled JSON I/O using XPCOM in B2G .jsm files.
--
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing
13 matches
Mail list logo
