Compiling apps that use dbus-cpp is way too slow and resource hungry
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dbus-cpp |
New
|
Undecided
|
Unassigned |
Bug Description
The way dbus-cpp's templating system works makes it extremely slow and cumbersome to use in day-to-day development. As an example, just compiling the benchmark application is incredibly slow. To test, have an up-to-date build of dbus-cpp and then do this:
touch ../examples/
time make
This takes almost 50 seconds on krillin and 5 seconds on an i7 desktop machine with 16 GB of ram. This makes any sort of iterative development infeasible.
As a symptom of this, rebuilding indicator-network on Jenkins takes about half an hour. Even worse is the fact that you can't compile in parallel, because every gcc process takes so much memory that if you spawn several the device runs out of memory and the OOM killer starts terminating your compile processes.
This even happens on laptops. If you have a machine with 4 cores and 4 gigs of RAM, you can't do -j4 because every gcc process takes about a gig of RAM leading to death by disk swapping.
For comparison, compiling a Qt5 app (from scratch) that uses roughly the same DBus interfaces as indicator-network takes less than a minute.
I have to agree with Jussi here. The duration of the build/test cycle has a direct relationship to the amount of time it takes me to fix a bug.
It kinda feels to me like I'd want to mainly use the introspection XML format (yes I know we all hate XML), which should generate stubs that maybe use non-typesafe calls (i.e. not using metaprogramming) in order to speed up compile times.
IMO it's just good practise to base your interfaces of the XML format anyway, so that you can include it in your devel package, and then other people can use it to generate e.g. Qt / GDBus stubs at compile time. The side benefit of this compared to copying introspection from a running service is that you get compile time consistency checks.