I don't understand why our results are so different. :(

You have my patch disabling the Zygote process applied, right?

On 26-03-2014 11:56, Long, Xiang wrote:
I did a test with all the 8 apps mentioned in your wiki, and here's my result:

1. ./xwalk --single-process --disable-extension-process app_id
Private  +   Shared  =  RAM used        Program
274.6 MiB +  91.1 MiB = 365.8 MiB       xwalk (8)
=================================

2. ./xwalk app_id
303.1 MiB + 111.2 MiB = 414.3 MiB       xwalk (48)

3. ./xwalk-launcher app_id with standalone EP
   3.6 MiB + 456.0 KiB =   4.0 MiB      xwalk-launcher (8)
208.4 MiB +  86.8 MiB = 295.2 MiB       xwalk (20)
--------------------------------- 299.3 MiB

4. ./xwalk-launcher app_id with merged EP
   7.1 MiB +   1.3 MiB =   8.5 MiB      xwalk-launcher (8)
186.9 MiB +  83.8 MiB = 270.7 MiB       xwalk (12)
--------------------------------- 279.2 MiB

Seems there's about 30% memory consumption increase between <1> and <4>.
However I still don't why we get the different result. I'm testing in Ubuntu 
13.10 VM with latest Crosswalk build.

And if we want some mechanism like current Tizen WRT process pool to optimize 
launch speed in single process mode, the memory difference will become larger.


-----Original Message-----
From: Crosswalk-dev [mailto:crosswalk-dev-boun...@lists.crosswalk-project.org]
On Behalf Of Thiago Marcos P. Santos
Sent: Wednesday, March 26, 2014 6:46 AM
To: crosswalk-dev@lists.crosswalk-project.org
Subject: [Crosswalk-dev] Crosswalk Shared Browser Process

Hi all,

I've been investigating how we run Crosswalk on Tizen for the past few
days and I would like to challenge the current model of sharing one
Browser Process for all the webapps.

I'm not convinced that the benefits (in terms of memory usage) are big
enough to justify the increasingly complexity of the source code related
to the Shared Browser Process in the Crosswalk tree.

Crosswalk should not be aware of any platform specifics like manifests,
sandboxing (smack labels), permissions, etc. This is how we do it
successfully for Android, Linux Desktop and Mac.

Therefore, tools like xwalkctl, xwalk-launcher, etc can still exist, but
as separated project outside the Crosswalk tree, since they are Tizen
specific, in the same way as the tizen-extensions-crosswalk.

This new xwalk-launcher could be a simple pre-loader (remember
maemo-launcher?) that would launch a self-contained instance of
Crosswalk (i.e. a Browser Process + Renderer Process) for each webapp.

With this change, we can can remove all the code from Crosswalk handling
manifests, permissions and shared browser process mode making the design
much more simple. We will also have the same execution model as we have
for Android, Mac and Linux, reducing the delta between the platforms we
support.

Here is the memory usage analysis I did with more details:
https://github.com/tmpsantos/crosswalk-process-model

I honestly don't think that with a pre-loader in place, the startup time
will be that different, but has to be tested. I invite everyone to join
me on this investigation, measuring launch time, performance, etc.

Cheers,
_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

_______________________________________________
Crosswalk-dev mailing list
Crosswalk-dev@lists.crosswalk-project.org
https://lists.crosswalk-project.org/mailman/listinfo/crosswalk-dev

Reply via email to