[prev in list] [next in list] [prev in thread] [next in thread] 

List:       klik-devel
Subject:    [klik-devel] Wondering about the fuse+fakechroot performances ?
From:       Lionel Tricon <lionel.tricon () free ! fr>
Date:       2007-02-25 18:13:13
Message-ID: 200702251913.13882.lionel.tricon () free ! fr
[Download RAW message or body]

Hello,

Interrested about the performance of the Fuse + Fakechroot solution, i have 
prepared a cmg package (iso format) for OpenOffice on my old suse 10.0 and 
tested deeply the bundle from the performance point of view. The fuseiso 
binary tested was including the union fuse + redirection r/w features.

For information, the cmg/iso file was about 314 Mo and include the following :
OpenOffice_org-2.0.4-1.10.i586.rpm
OpenOffice_org-fr-2.0.4-1.10.i586.rpm
OpenOffice_org-galleries-2.0.4-1.10.i586.rpm
OpenOffice_org-gnome-2.0.4-1.10.i586.rpm
OpenOffice_org-kde-2.0.4-1.10.i586.rpm
OpenOffice_org-officebean-2.0.4-1.10.i586.rpm

After a reboot to flush the system, the first test consisted to launch 
oowriter (installed on the system) and to exit quickly with the ctrl-Q 
command when the graphical interface was ready. The "time" command give us 
useful informations about the time that takes to start (not very accurate but 
it's better than nothing).

The next value consisted to run oowriter a second time to take advantage of 
the virtual memory layer. That's why it's better.

-- REAL

real    0m8.003s	+/- 0.5
user    0m0.008s
sys     0m0.012s

real    0m6.978s
user    0m0.004s
sys     0m0.016s

After a reboot and the removal of the OpenOffice package from the disk, i have 
tested the cmg file. You can see below that it takes 9.5 seconds more to 
start.

-- CMG FILE

real    0m17.591s	+/- 0.3
user    0m0.012s
sys     0m0.004s

real    0m8.947s
user    0m0.000s
sys     0m0.028s

The last test consisted to reinstall the OpenOffice package and to ran 
oowriter but inside an empty cmg file. The idea was to avoid the use of any 
kind of embedded data into the cmg file but to use the one located into the 
real filesystem, from isofs+fakechroot. In this test, the interrested is that 
you can evaluate more precisely the time spend into all the new code i have 
added into the fuseiso+fakechroot code base.

The machine was rebooted before as usual.

-- CMG FILE EMPTY

real    0m10.926s	+/- 0.6
user    0m0.008s
sys     0m0.020s

real    0m8.643s
user    0m0.012s
sys     0m0.024s

So, my conclusion (except that my computer is slow a lot !) is that reading 
openoffice data from an iso image through fuseiso takes 6.5 seconds and that 
you spend a maximum of 3 seconds into the fakechroot+union+redirection 
implementation (all of these compared to the 8 seconds to start the 
application in the real life).

So, if you consider that you spend 100% more compared to the real application, 
you spend 2/3 into fuseiso and 1/3 into all additional features.

Good or bad ? After the application is started, it's not perceptible from the 
user point of view. But keep in mind that if someone want to use fuseiso into 
his own proposal, it would cost a lot for reading data (2/3 of the original 
time).

And we need to consider as well that openoffice is a really big package with a 
lot of files to load ...

Maybe a solution based on an unionfs build directly into the kernel and a 
chroot or equivalent hack could get better performance but you have to 
consider that your gain will not exceed 37.5% of the original time. All the 
rest will be spend into fuseiso. Obviously, you can use the isofs build into 
the kernel, but it's a less beautiful solution that the one which use fuse 
with a lot of constraints.

Lionel

ps : hope my poor english is not to difficult to understand and is clear 
enough ...
_______________________________________________
klik-devel mailing list
klik-devel@kde.org
https://mail.kde.org/mailman/listinfo/klik-devel
[prev in list] [next in list] [prev in thread] [next in thread]