On 11/3/14 11:12 AM, Carlos Garcia Campos wrote:
El lun, 03-11-2014 a las 00:22 -0800, Benjamin Poulain escribió:
On 11/2/14, 1:11 AM, Carlos Garcia Campos wrote:
El sáb, 01-11-2014 a las 20:43 +0200, Antti Koivisto escribió:
On Sat, Nov 1, 2014 at 10:13 AM, Carlos Garcia Campos
<carlo...@webkit.org> wrote:
El vie, 31-10-2014 a las 19:02 +0200, Antti Koivisto escribió:
> Hello,
>
>
> I'm planning to add an experimental HTTP cache
implementation to
> WebKit (https://bugs.webkit.org/show_bug.cgi?id=30322).
Great news!
> The main motivations are:
>
>
> - Improving performance by bringing the cache closer. For
example we
> can serialize WebKit response objects directly instead of
converting
> to/from platform types.
> - Making future innovation around caching easier. Closer
coordination
> between cache and WebKit opens new optimization
possibilities.
>
>
> The cache lives in the network process. Most of the code is
> cross-platform. The storage backend uses libdispatch IO
though it
> wouldn't be hard to add a generic posix one too.
Why is it limited to the network process? wouldn't it be
possible to use
it also in the web process when shared secondary process model
is used?
The cache ties to NetworkResourceLoader which lives in the network
process. In principle it would be possible to integrate with the web
process side resource loader too. However I don't want to support
multiple configurations during development.
It would be good if all WK2 ports would eventually switch to using the
network process. The current multitude of configurations makes
networking related code more confusing and less hackable than it needs
to be.
The GTK+ port supports the network process, but it's only used when
multiple secondary process model is used. Some applications prefer the
single shared secondary process model, and even some of the browser
users change the default process model of epiphany to single web process
because it requires fewer resources. So, we could either integrate the
cache with the web process loader, or use the network process
unconditionally for all process models. I think for many simple
applications a single web process is the most efficient model, though.
I believe it would be better to enable the network process for all
process models. Maintaining multiple configurations for marginal gains
is not sustainable, especially in the network stack.
You say a single Web Process is the most efficient model for some
applications. What is the impact of always enabling the network process on:
-CPU load?
-Memory load?
-Overall performance?
I haven't measured, I was thinking mainly on the overhead of the IPC
traffic required for the network resources.
On iOS, we managed to optimize this until IPC was no longer a major
performance concern. Our IPC should definitely improve but it is not a
high priority for performance.
You could argue that iOS runs on very unconventional CPUs but we also
have some old ARMv7 that are close to conventional CPU and we managed
reasonable overhead on those too.
In my humble opinion, we should just get hard data and solve the actual
problems (which I suspect may be memory and not IPC).
Benjamin
Once we know where the problems are, we should work together at reducing
the impact. I suspect we can get the network process below 5% overhead.
Benjamin
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
