Consider dropping maemo-launcher/maemo-invoker

[IMbackK]

I would like to discuss dropping maemo-launcher, because i contend that its is a outsized maintenance burden compered to its benefit. Lets examine these 2 claims:

1. Maemo-launcher is a maintenance burden

• we currently cant update libc because the hacky way maemo-launcher implements executing its binarys. the way used to be able to launch directly and via the launcher dose not work with modern libc
  • fixing this requires fairly invasive changes to all maemo-launcher applications or loosing the ability to run them without the launcher
• every binary which we want to benefit from maemo-launcher needs to have its packaging and compile options changed
  • if maintaining maemo-launcher is to be worth it this needs to be a non trivial portion of the applications expected to be installed on a typical system
  • currently very few packages use maemo-launcher
• for every libary that we want to have accelerated by mameo-launcher a boost module needs to be written
  • this is not entirely trival, understaning of the lib in question is needed
  • currently only obsolete libs have boost modules
  • the modules do things that are not stable between lib versions
    • As soon as they are applied to libs that are not dead/obsolete this will cause further maintenance burden
  • iiuc how this works symbol conflicts are inevitable if many libs are added
    • please correct me if i am wrong on this point
• maemo-launcher causes other unexpected problems, sutch as preventing the launch of applications via symlink see hildon-desktop launcher needs to honour (or hide apps with) the Terminal=true setting #415

2. Compared to the above the performance benefits are minimal:

Methodology:

1. A droid 4 was used, with leste installed on my high speed sdcard with the 100MHz sdcard clock hack applied
   • this is the fastest storage available on the droid 4, and afaik leste in general.
   • this should magnify the benefit of maemo-launcher by making symbol resolution a larger part of the total compared to disk access.
2. "cold" start tests where performed after executing "echo 2 > /proc/sys/vm/drop_caches"
3. "warm" start tests where performed after executing the application twice first.
4. all tests where repeated 3 times and the mean is presented.

time /usr/bin/osso-xterm /bin/true:
maemo-launcher cold:

real    0m0,756s
user    0m0,000s
sys     0m0,014s

regular cold:

real    0m1,050s
user    0m0,453s
sys     0m0,132s

maemo-launcher warm:

real    0m0,695s
user    0m0,001s
sys     0m0,017s

regular warm:

real    0m0,776s
user    0m0,342s
sys     0m0,127s

time osso_pdfviewer:
Next i hacked a version of osso_pdfviewer to return 0 here: https://github.com/maemo-leste/osso-pdf-viewer/blob/4dc68586008aa30781c11e4f9f9bbfb16dfc43ca/src/main.c#L152
I expected this to be best case for maemo-launcher since the application dose very little except the stages accellerated by maemo-launcher.

maemo-launcher cold:

real    0m0,408s
user    0m0,000s
sys     0m0,016s

regular cold:

real    0m0,706s
user    0m0,314s
sys     0m0,150s

maemo-launcher warm:

real    0m0,337s
user    0m0,000s
sys     0m0,018s

regular warm:

real    0m0,397s
user    0m0,205s
sys     0m0,144s

Conclusion
Based on the above it seams to me that the main benefit of maemo-launcher is that the libs required to launch the application do not have to be loaded from disk on a cold start.
Comparatively the benefit from reduced overhead from ld seams to be tiny even in the best case tests above, in more complex applications the benefit will be comparatively much smaller still. The cold start performance could basically be matched without any hacky dlopen() path by avoiding loading from disk via Preload or systemd-readahead-replay.

[clort81]

This is valuable thank you. However wouldn't the difference be bigger without the fast 100mhz sd card hack?

[IMbackK]

no, faster strorage means that symbol resolution and gtk init takes up a larger percentage of time.