|
|
|
|
README
|
|
|
|
|
|
|
|
|
|
tdeinit is a process launcher somewhat similar to the
|
|
|
|
|
famous init used for booting UNIX.
|
|
|
|
|
|
|
|
|
|
It launches processes by forking and then loading a
|
|
|
|
|
dynamic library which should contain a 'main(...)'
|
|
|
|
|
function.
|
|
|
|
|
|
|
|
|
|
Executive summary
|
|
|
|
|
=================
|
|
|
|
|
|
|
|
|
|
Using tdeinit to launch KDE applications makes starting
|
|
|
|
|
a typical KDE applications 2.5 times faster (100ms
|
|
|
|
|
instead of 250ms on a P-III 500) It reduces memory
|
|
|
|
|
consumption by approx. 350Kb per application.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
How it works
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
tdeinit is linked against all libraries a standard KDE
|
|
|
|
|
application needs. With this technique starting an
|
|
|
|
|
application becomes much faster because now only
|
|
|
|
|
the application itself needs to be linked whereas
|
|
|
|
|
otherwise both the application as well as all the libaries
|
|
|
|
|
it uses need to be linked.
|
|
|
|
|
|
|
|
|
|
Startup Speed
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
Starting an application linked against libqt, libtdecore and libtdeui
|
|
|
|
|
in the conventional way takes approx. 150ms on a Pentium III - 500Mhz.
|
|
|
|
|
Starting the same application via tdeinit takes less than 10ms.
|
|
|
|
|
|
|
|
|
|
(application without KApplication constructor, the KApplication
|
|
|
|
|
constructor requires an extra 100ms in both cases)
|
|
|
|
|
|
|
|
|
|
Memory Usage
|
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
An application linked against libqt, libtdecore and libtdeui started
|
|
|
|
|
in the conventional way requires about 498Kb memory.
|
|
|
|
|
(average of 10 instances) If the same application is started via
|
|
|
|
|
tdeinit it requires about 142Kb. A difference of 356Kb (application
|
|
|
|
|
without KApplication constructor)
|
|
|
|
|
|
|
|
|
|
If we take the KApplication constructor into account, an application
|
|
|
|
|
started in the conventional way takes about 679Kb memory while the same
|
|
|
|
|
application started via tdeinit requires about 380Kb. Here the difference
|
|
|
|
|
is somewhat less, 299Kb. This seems to be caused by the fact that the
|
|
|
|
|
dynamic linker does "lazy linking". We can force the linker to link
|
|
|
|
|
everything at startup by specifying "LD_BIND_NOW=true". When tdeinit is
|
|
|
|
|
started with this option on, tdeinit is back to its full efficiency, an
|
|
|
|
|
application with a KApplication constructor now uses 338Kb of memory.
|
|
|
|
|
A difference of 341Kb with the normal case.
|
|
|
|
|
|
|
|
|
|
Adapting programs to use tdeinit.
|
|
|
|
|
===============================
|
|
|
|
|
|
|
|
|
|
The sourcecode of a program does not require any change to take advantage
|
|
|
|
|
of tdeinit. Only the makefile requires an adaption, if the Makefile.am of
|
|
|
|
|
a normal program looks like this:
|
|
|
|
|
|
|
|
|
|
bin_PROGRAMS = kicker
|
|
|
|
|
kicker_LDADD = $(top_builddir)/libkonq/libkonq.la
|
|
|
|
|
kicker_LDFLAGS = $(all_libraries) $(KDE_RPATH)
|
|
|
|
|
|
|
|
|
|
The following lines need to be added to make a library version useable
|
|
|
|
|
by tdeinit:
|
|
|
|
|
|
|
|
|
|
lib_LTLIBRARIES = kicker.la
|
|
|
|
|
libkicker_la_LIBADD = $(top_builddir)/libkonq/libkonq.la
|
|
|
|
|
libkicker_la_LDFLAGS = $(all_libraries) $(KDE_RPATH) -module
|
|
|
|
|
|
|
|
|
|
Disadvantages
|
|
|
|
|
=============
|
|
|
|
|
|
|
|
|
|
The process name of applications started via tdeinit is "tdeinit". This problem
|
|
|
|
|
can be corrected to a degree by changing the application name as shown
|
|
|
|
|
by 'ps'. However, applications like "killall" will only see "tdeinit" as
|
|
|
|
|
process name. To workaround this, use "kdekillall", from kdesdk/scripts,
|
|
|
|
|
for applications started via tdeinit.
|
|
|
|
|
|
