From klik-devel Sun Feb 25 18:13:13 2007 From: Lionel Tricon Date: Sun, 25 Feb 2007 18:13:13 +0000 To: klik-devel Subject: [klik-devel] Wondering about the fuse+fakechroot performances ? Message-Id: <200702251913.13882.lionel.tricon () free ! fr> X-MARC-Message: https://marc.info/?l=klik-devel&m=117242720618321 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