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
I did a very quick inspection of some relatively recent code,
Webapps.jsm, to find out why even recent code isn't using the encoding
conversion facilities that the Web offers and is instead using XPCOM
facilities.
The quick answer seems to be that the reason for not using Web APIs
for encoding con
14 matches
Mail list logo
