Re: [webkit-dev] Disk cache

2014-11-03 Thread Benjamin Poulain

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?

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


Re: [webkit-dev] Streams API

2014-11-03 Thread youenn fablet
Hi Benjamin,

 I have two concerns:
 1) You have many patches waiting for review. I think you need to get better
 communication channels with reviewers in order to iterate over your patches
 faster. It is unfortunate but getting complex patches reviewed in WebKit
 requires poking reviewers directly. Since you work on the network stack, I
 suggest asking Alexey (ap) and Pratik (psolanki) on IRC, they can help with
 reviews or suggest other reviewers.

Thanks for the suggestion, I will try to do so for my pending patches.
For the particular streams API work, I am teaming up with some Igalia fellows.
I hope that we can make good progress that way.

 2) Streams is a large spec and it touches platform code. Please be careful
 with stability, make more tests than reasonable and #ifdef everything.

 I suggest the flag name ENABLE_STREAMS_API, I find ENABLE_STREAMS a bit
 too generic.

Ah, I was thinking of using ENABLE_STREAMS.
ENABLE_STREAMS_API is fine by me.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Disk cache

2014-11-03 Thread Anders Carlsson

 On Nov 3, 2014, at 12:22 AM, Benjamin Poulain benja...@webkit.org wrote:

 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.

I agree 100%. Not to mention that we also want to get rid of the “single web 
process” code path, and just make it a special case of having multiple web 
processes with a maximum process cap of 1.

- Anders

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev


Re: [webkit-dev] Disk cache

2014-11-03 Thread Brent Fulgham
I wonder if we could easily modify the Windows port to make use of a Network 
process.

-Brent

 On Nov 3, 2014, at 8:07 AM, Anders Carlsson ander...@apple.com 
 mailto:ander...@apple.com wrote:
 
 
 On Nov 3, 2014, at 12:22 AM, Benjamin Poulain benja...@webkit.org 
 mailto:benja...@webkit.org wrote:
 
 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.
 
 I agree 100%. Not to mention that we also want to get rid of the “single web 
 process” code path, and just make it a special case of having multiple web 
 processes with a maximum process cap of 1.
 
 - Anders
 
 ___
 webkit-dev mailing list
 webkit-dev@lists.webkit.org mailto: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


Re: [webkit-dev] Disk cache

2014-11-03 Thread Carlos Garcia Campos
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.

 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


Re: [webkit-dev] Disk cache

2014-11-03 Thread Benjamin Poulain

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