Images in a Multiprocess World
Bobby Holley
I put together a design document on the work I'm going to be doing on
multiprocess image handling for Electrolysis. It's on the wiki at https://wiki.mozilla.org/Multiprocess_Images
I'd appreciate any input or feedback on the matter.
Cheers,
-bholley
Boris Zbarsky
Some thoughts:
1) What are the benefits of sharing the image cache between all content
processes? Some of the drawbacks are obvious: stopping animations in
one tab stops animations of the same images in other tabs, for example.
How common is it that different tabs/windows really share the same
images? Would things be better in that regard if we used
process-per-domain or some such? Or otherwise grouped multiple tabs
into a single process?
2) The current plan assumes that content/layout consumers will just
keep calling loadImage. But they need to make a content policy call
before doing that; will content policies run in the renderer processes
or in chrome? If the latter, then presumably the loadImage shouldn't
run in the renderer process either.
3) Similar for security checks (which also need to happen before loadImage).
-Boris
Benjamin Smedberg
It's not clear to me that a shared image cache is necessary or desirable.
From the document, the main reason for a shared cache is to avoid
"downloading and decoding the same image multiple times unnecessarily
(TODO-elaborate). "
I would hope, though, that the network cache, which is planned to be shared,
would take care of making sure we don't download images twice. Is image
decoding really an expensive-enough operation that we want to add lots of
extra machinery?
I figured the major reason to share the image cache would be to avoid the
memory overhead of having the same decoded image data in multiple processes.
But I think we'd actually need to collect data about whether users would
actually end up with multiple unrelated tabs with many shared images before
trying to implement a complex shared solution.
--BDS
Joe Drew
On Jun 23, 2009, at 10:17 AM, Benjamin Smedberg wrote:
> I would hope, though, that the network cache, which is planned to be
> shared,
> would take care of making sure we don't download images twice. Is
> image
> decoding really an expensive-enough operation that we want to add
> lots of
> extra machinery?
We already have that extra machinery in the form of the image cache.
Decoding on its own isn't that expensive, but doing it over and over
for the same images sucks, and breaks some web consumers (see bug
466586).
Benjamin Smedberg
I believe that with multi-process we're unlikely to be using the same image
in multiple tabs, and we could just use a per-process image cache. Are you
saying there are web-compat issues where if we had a per-process image cache
backed by the necko HTTP cache we'd somehow cause problems for websites?
--BDS
Joe Drew
On Jun 23, 2009, at 12:43 PM, Benjamin Smedberg wrote:
> I believe that with multi-process we're unlikely to be using the
> same image
> in multiple tabs, and we could just use a per-process image cache.
> Are you
> saying there are web-compat issues where if we had a per-process
> image cache
> backed by the necko HTTP cache we'd somehow cause problems for
> websites?
No, definitely not. I was perhaps reading too much into what you'd
written, which sounded like it was advocating getting rid of the image
cache altogether.
Benjamin Smedberg
> No, definitely not. I was perhaps reading too much into what you'd
> written, which sounded like it was advocating getting rid of the image
> cache altogether.
Oh, not at all! Just not doing new work to share the image cache across
multiple processes.
--BDS
Lucas Adamski
images across tabs is actually fairly frequent occurrence when the
tabs are all from the same site. FWIW my pattern for reading news is
to open up a new tab for each interesting story, then close them as I
read each one. Maybe I'm an anomaly in that case. Performance wise
we might be damned if we do or damned if we don't.. pageload latency
and network cost vs increased IPC overhead. We'd also be responsible
for a not-insignificant increase in server loads for most websites.
It might also making scaling to many processes harder in the future
due to memory consumption issues, unless we have a dynamic per-proc
cache size limit?
I'm also wondering if there might be concerns about the same image
being out of sync between tabs, but maybe there's really no guarantee
of that anyway given cache performance is not very reliable from a web
dev perspective.
Lucas.
> _______________________________________________
> dev-tech-dom mailing list
> dev-te...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-tech-dom
Benjamin Smedberg
> I have no evidence to back this up but it does seem like sharing images
> across tabs is actually fairly frequent occurrence when the tabs are all
> from the same site. FWIW my pattern for reading news is to open up a
> new tab for each interesting story, then close them as I read each
> one. Maybe I'm an anomaly in that case. Performance wise we might be
> damned if we do or damned if we don't.. pageload latency and network
> cost vs increased IPC overhead. We'd also be responsible for a
I suspect that same-domain loads will normally be handled by the same
process, even if they happen to occur in multiple tabs. But again, without
measurement this seems like a premature optimization.
We shouldn't incur any network cost in the common cases, assuming the HTTP
cache behaves reasonably. Duplicate memory usage is more concerning...
perhaps we can arrange for global control of all the caches in some manner
if that shows up as a significant issue.
--BDS