On Tue, 2014-09-16 at 18:34 +0200, Jacek Bukarewicz wrote:
> > For use in production you are right, we need some benchmarking. Both
> > memory overhead and startup latency as mentioned by Dominig are
> > relevant. Do we have tools in Tizen for measuring shared vs. unshared
> > memory mappings? More specifically, how did you identify the 1.5 MB
> > number above?
> >
> > I fixed the Tizen-specific issues that I mentioned in my announcement,
> > so I can run some benchmarks on a VTC1010 now.
> >
> I used simple test script (hello.py):
> #! /usr/bin/python
>
> print 'Hello World'
> raw_input()
>
>
> On the second terminal I ran:
> top -p $(pgrep hello.py)
>
> I got such results:
> PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
> 2507 root 20 0 5956 3080 1452 S 0.0 0.1 0:00.01 hello.py
>
> RES column denotes how much physical memory given process uses. SHR
> shows how much physical memory is shareable. I assume that the rest is
> private to the process (about 1.6 MB).
Okay, let's use this. I know that people have come up with fancy scripts
for parsing the system memory map to handle shared pages better (for
example, attributing a proportional share of them to each process using
them). When focusing on unshared memory that's not necessary.
On Tizen, I used xwalk-launcher to render a simple .html file
(attached). xwalk-launcher connects to the user's shared browser process
(auto-activated via D-Bus if not running yet) and then becomes the
per-user and per-app extension process. In other words, extensions get
loaded into xwalk-launcher.
I used this command line to sum up all running xwalk and xwalk-launcher
processes:
top -n 1 $(pidof xwalk-launcher xwalk | sed -e 's/\([0-9]*\)/-p \1/g') | \
perl -e '$res = 0; $shared = 0; while(<>) { if (/app *(\d+) *(\d+) *(\d+)
*(\d+) *(\d+)/) { $res += $4; $shared += $5; } }; print "total resident
${res}KB - shared ${shared}KB = private ", $res - $shared, "KB\n";'
Beware that both the resident and shared memory size is counting pages
multiple times, so only the private part is really meaningful.
My system is a VTC1010, Tizen IVI tizen-ivi_20140910.4_ivi-mbr-i586,
updated via zypper today, giving me crosswalk-9.37.193.0-13.15.i686 and
tizen-extensions-crosswalk-0.92-13.1.i686.
>From now on, I repeat the measurement five times, killing xwalk each
time, because it turned out that the numbers are not very stable.
Without any extensions, I get:
total resident 80492KB - shared 50012KB = private 30480KB
total resident 75940KB - shared 49836KB = private 26104KB
total resident 80512KB - shared 49932KB = private 30580KB
total resident 76348KB - shared 49928KB = private 26420KB
total resident 73968KB - shared 47800KB = private 26168KB
77452 49502 27950
Averages with the standard tizen-extensions-crosswalk:
85726 55788 29938
And now also with pycrosswalk+cloudeebus:
91651 57922 33728
So adding pycrosswalk+cloudeebus increases the total memory footprint
(by 5925KB, which can be calculated because the extra pages only get
loaded into one process), of which 3790KB are due to per-app memory.
So in summary, running a web app costs ~29MB. Including cloudeebus
increases that by 12%. That can be ignored for prototyping, but may or
may not matter in production.
Remember that his is pretty much a worst-case scenario. A more complex
web app will already have a larger memory consumption, so the relative
overhead for using Python in an extension will be smaller.
There are more additional shared pages than in your stand-alone python
invocation because additional modules get imported. Checking python on
the following script gives comparable numbers to pycrosswalk+cloudeebus:
#! /usr/bin/python
import dbus
import dbus.service
import re
import json
from twisted.python import log
from xml.etree.ElementTree import XMLParser
from twisted.internet import defer
print 'Hello World'
raw_input()
1397 app 20 0 11668 7056 2704 T 0.0 0.4 0:00.17 python
The amount of private memory will of course go up when actually using
cloudeebus. The cloudeebus-example packages will have a D-Bus client and
server example, to be launched with client.sh and server.sh
from /usr/share/doc/cloudeebus/examples/agent.
Both examples only use cloudeebus after hitting a button. However, that
also changes the rendered HTML content, so it is hard to tell how much
the increase in memory is caused by initializing Python objects.
Now, regarding loading time for the extensions.
I wanted to use perf with entry/exit probes for the relevant method in
xwalk-launcher
(xwalk::extensions::RegisterExternalExtensionsInDirectory), but the
Tizen IVI kernel is compiled without CONFIG_KPROBE_EVENTS, so that
doesn't work.
So instead I used "strace -tt -e trace=open" and just looked at the time
stamps where it starts opening files for the extensions until it is
done.
The initial time for loading all extensions with absolute nothing cached
(echo 3 > /proc/sys/vm/drop_caches) is almost exactly a second. The next
runs only take 0.7s. The time from starting to load
libxwalkcloudeebus.so to the next extension is 0.64s (cold) and 0.53s
(warm).
This is with the internal SSD of the VTC1010. However, strace needs to
log a lot more open() calls during the initialization of python
(including many failed attempts while searching for files); I have no
idea if or how much slowdown that causes. I guess I have to double-check
by recompiling a modified Crosswalk.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
hello world
_______________________________________________
Dev mailing list
[email protected]
https://lists.tizen.org/listinfo/dev
