PSA: Please do not use large data: URIs.

[Justin Lebar]

This is a public service announcement.

Data URIs are memory-inefficient.

Encoding a binary file as a data URI causes its size in memory to
increase by a factor of ~2.7x.

Using data URIs usually entails copying them. For example, if you
want to use a data URI as a DOM element's background via
"url(data:...)", Firefox makes a copy of that data URI.

If you use that same data URI in multiple places, we end up making
multiple copies of it, further compounding the problem.

Please be aware of the size of your data URIs. If the URI is a
screen-sized image (e.g. a background, or a screenshot), or a large
file (e.g. a ringtone), please do not use a data URI.

This has been a public service announcement. Thank you.

https://bugzilla.mozilla.org/show_bug.cgi?id=820940

[Scott Michaud]

Actually this raises a good question which I have yet to test: Is there
really any benefit to using a locally hosted Data URI especially when
GAIA is contained on solid state storage? Most decent SSD controllers
have pretty linear scaling of (I/O) transactions per second (IOPS) up to
about 4-8 simultaneous events so the drive should scale up as demand
increases.

http://www.pcper.com/image/view/18605?return=node%2F55930

Unless the manufacturer uses a terrible SSD controller if I had to guess
I'd expect the increase in size and b64->bin conversion time would
almost always be a performance sink... I mean unless you would have a
really long file path?

Opinions?

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia
>

[Justin Lebar]

On Wed, Dec 12, 2012 at 3:50 PM, Scott Michaud <sc...@loosescrew.ca> wrote:
> Actually this raises a good question which I have yet to test: Is there
> really any benefit to using a locally hosted Data URI especially when GAIA
> is contained on solid state storage?

If you really must keep the file in memory, you can use a blob. Blobs
are manually refcounted, which is a pain. But on the upside, you
don't have to make a copy to use it in CSS, and you don't get the 2.7x
inflation in memory.

So the question should be whether there's any advantage to using blobs
over on-disk files.

[Julien Wajsberg]

Le 12/12/2012 21:50, Scott Michaud a écrit :
> Actually this raises a good question which I have yet to test: Is
> there really any benefit to using a locally hosted Data URI especially

> when GAIA is contained on solid state storage? Most decent SSD
> controllers have pretty linear scaling of (I/O) transactions per
> second (IOPS) up to about 4-8 simultaneous events so the drive should
> scale up as demand increases.
>
> http://www.pcper.com/image/view/18605?return=node%2F55930
>
> Unless the manufacturer uses a terrible SSD controller if I had to
> guess I'd expect the increase in size and b64->bin conversion time
> would almost always be a performance sink... I mean unless you would
> have a really long file path?

The Flash storage we use on our dev phone is quite the slowest one
anybody has ever seen and we expect this will be the same in the final
phone.

--
Julien

[Scott Michaud]

The concern is not really the speed of the flash (because it is the same
component in both cases), it is how to make the storage slow down the
least. Brought this up with a coworker (Allyn Malventano, storage
reviewer) and he had some interesting points.

1) Mobile flash controllers mostly cannot do concurrent I/O requests --
but that doesn't matter.

2) If you hit the file system more, you will be doing a bit more CPU
work fetching where the files are -- but obviously not a lot. It's not
like you're trying to make another network connection to a server.

3) Flash Memory pages are 2kb in size and random access by nature. If
your file gets close to 2kb (like, >1kb) you will be doing the same
number of requests regardless... except for file table look-up.

So if your system has a bunch of <<< 2kb files (like, 10's or low-100's
of bytes) then "they should be packaged together into some sort of
container format." He suggested some sort of prefetching done by B2G so
if you call a cached file it just points to its location in RAM which
could be freed if needed by something else... but that's not a topic for us.

------ TL;DR: ------

What is for us is that Base64 will basically just hurt you with
overhead, ballooned memory usage, and development time unless your files
are <<< 2kb. Theoretically sprites should help if the overwhelming
majority will always be loaded together such as a pack of really small
textures for a game or something -- but how much? Who knows.