maemo-launcher performance test
9. March 2007
Today was the time to get some results on the improvements that can be reached using maemo-launcher. Of course all this tests might be inaccurate and wrong…
At first, I needed a simple example so I took the Hello World! example from the Gtk+ Tutorial. The only code change was to add a GTimer and to print the elapsed time before gtk_main() is called. I now made some test runs (not enough for a statistical correct result…).
Result Gtk: maemo-launcher speeds up this example by about 25%. That could mean the Gtk initialisation takes about 25% of the start-up time. Of course in bigger applications this value will decrease as they do much more than just to init Gtk and create some widgets.
So, the next step was to test what happens to an application that uses Gtkmm instead of Gtk. Again, I used the simplest example from the tutorial, Hello World in gtkmm and modified it to install a timer before Gtk::Main::run(). This test did not give me that nice results as the above. The standard deviation was much higher so I assume caching has a much bigger influence here.
Result Gtkmm: The speed-up reached by the launcher using the gtk booster was about 22% in average but in a range from +54% to -59%. If I used the new gtkmm booster together with the gtk booster I gained 35% more speed and the range was only +65% to -11%.
Overall results: It seems like maemo-launcher does speed things up a bit. On my laptop this only means some milliseconds but maybe it is more important on embedded platforms. I still wonder why I have such a big standard deviation with the C++ code. You can have a look a the exact results (gnumeric sheet)
All this was done using gtk+ 2.10.9, gtkmm 2.10.8 and maemo-launcher from SVN TRUNK. I had to modify the Gtk booster to work with 2.10 which means that it does only init all the GTypes but avoids all the more advanced hacks that no longer work because many leaks in Gtk have been fixed.
Toolbars without bonobo?
7. March 2007
After Murray pointed out that bonobo will be deprecated in GNOME 2.18 (thanks!) I wonder how to implement this nice dockable toolbars in the future. Of course HIG-fetishists will say that they are overkill but in feature and UI monsters like Anjuta they are not really avoidable.
It depends very much on your workflow which toolbars you find useful and which not and how you want to arrange them especially on small screens. Without being able to dock them this is difficult to archive.
P.S: Some complained it’s difficult to contact me! It’s not: jhs(at)gnome.org
Quo vadis bonobo?
5. March 2007
Recently I hacked on the Anjuta toolbar system to split the big toolbars into several smaller ones. Of course the layout of those toolbars needs to be saved across sessions. This is not really difficult but I soon found me in the situation where I just scrolled around svn.gnome.org to find out what the methods in libbonoboui do because there is no real documentation.
The code is mostly clean and the functionality is also great but this seems one of the parts of GNOME that are not really maintained. I never found any notice that bonobo is deprecated so I guess other also find this useful. At least this is the easiest way to get plugable toolbars which are really useful for applications that provide a lot of toolbar buttons. Of course libbonoboui might be able to do much more, I just did not hit other parts yet.
So, what is the status of bonobo? Is there some roadmap and will it survive project ridley?
More gtkmm-booster for Maemo
5. March 2007
Today, I hacked a bit on maemo-launcher to add support for multiple boosters. It was not very difficult but quite annoying because string handling and lists without Glib are a real mess!
The gtkmm-booster seems to work good now and I had no problems to launch the complete maemo-desktop and the maemomm-helloworld example. There are some instructions in the README to set up the launcher correctly.
Anyway, I still miss a real-life test-case and good ideas how to measure the performance. My laptop might be about 10 times faster as the N800 so I can’t “feel” any performance changes. I also have no real idea how to get objective results.
maemo gtkmm booster
1. March 2007
To speed up application start-up the clever people at Nokia wrote Maemo launcher. It is a quite dirty hack that tries to keep many things in memory and to fork to main() once an application is started.
Of course something like this would be nice for gtkmm/maemomm too. maemo-launcher supports different booster modules and thus we can add a gtkmm booster modules. I spent most of the day figuring out how all this works and finally finished a very simple booster. The gtkmm booster currently simply calls the methods from the gtk booster (as we need all the stuff from gtk anyway) but in the future it will also do some gtkmm specific stuff.
If you are interested you can have a look at the sources (you will also need the patch from this bug against maemo-launcher). It is still broken in many places but at least you should be able to start some apps. Start the launcher using maemo-launcher --daemon --send-app-died --booster gtkmm.
MySQL on Maemo
28. February 2007
I recently tried to build mysql packages to be able to access the client libs from libgda(mm) on maemo bora. I figured out how to build them on SDK_X86 by cutting down depencies as much as possible but failed to build them on SDK_ARMEL because of this internal compiler error:
if arm-linux-gnueabi-g++ -DHAVE_CONFIG_H -DNDEBUG -I. -I. -I../../../../.. -I. -I../../../../../include -I../../../../../ndb/include -I../../../../../ndb/src/kernel/vm -I../../../../../ndb/src/kernel/error -I../../../../../ndb/src/kernel -I../../../../../ndb/include/kernel -I../../../../../ndb/include/transporter -I../../../../../ndb/include/debugger -I../../../../../ndb/include/mgmapi -I../../../../../ndb/include/mgmcommon -I../../../../../ndb/include/ndbapi -I../../../../../ndb/include/util -I../../../../../ndb/include/portlib -I../../../../../ndb/include/logger -O3 -DDBUG_OFF -fno-implicit-templates -fno-exceptions -fno-rtti -MT Cmvmi.o -MD -MP -MF ".deps/Cmvmi.Tpo" -c -o Cmvmi.o Cmvmi.cpp; \
then mv -f ".deps/Cmvmi.Tpo" ".deps/Cmvmi.Po"; else rm -f ".deps/Cmvmi.Tpo"; exit 1; fi
Cmvmi.cpp: In member function `void Cmvmi::execTESTSIG(Signal*)':
Cmvmi.cpp:1463: internal compiler error: in verify_local_live_at_start, at flow.c:546
Please submit a full bug report,
with preprocessed source if appropriate.
Send email to arm-gnu@codesourcery.com for instructions.
It’s not a major issue as I was able to build PostgreSQL packages and one database is enough in the moment but if someone has an idea what I could do about it I would be glad to hear.
In the meantime a have put up a small howto for installing an SDK for C++ development on the Nokia N800.
Bad ideas!
19. February 2007
It was a real bad idea to fix the anjuta .desktop file recently to allow proper bugs reports in bugzilla. People just file to many crash bugs now…
Linus’ metacity patches
17. February 2007
So, I just read Christan Schaller’s blog about the patches Linux Torvalds submitted to metacity and control center.
As that is not really mentioned anywhere (and I had to search various mailing list archives) here is the original mail, so anyone can get an idea of what these patches do and why someone would want to have this options. I don’t know if this patches a good, useful, whatever.
I am just a bit upset about the way this communication happened between people from GNOME and some contributor. I say some contributor here because we should not make any difference between people willing to help us. Linus is like anyone else and if he sent patches to the wrong mailing list than we can politely tell him. Of course, Linus might not have ever been fair to the GNOME community but nevertheless nobody should treat him differently than anybody else therefore (see Code of Conduct).
GNOME rocks! Let’s make it even better!
Anjuta 2.1.1
12. February 2007
So not even one month after the last release, anjuta 2.1.1 hits the road. We have fixed a lot of annoying bugs so I hope you will enjoy this release. We will continue to concentrate on bug-fixing but will probably create some interesting branches in the meantime to get even more cool feature in. Grab it from Anjuta.org!
As Murray already posted we at Openismus are still working on finishing libgdamm and libgnomedbmm. We did not expect that we would have to work so much on the C sources (see my previous post) but I hope we can finish them soon.
Use construct properties
2. February 2007
This is a comment for all people writing GObject-style libraries that may have to be wrapped for other programming languages (C++, etc). And as you only write cool libraries which will be that useful that they will one day be wrapped, this applies to all your libraries.
Construct properties
Add a property for every parameter of your _new method. These parameters can be restricted to G_PARAM_WRITABLE|G_PARAM_CONSTRUCT_ONLY if it is useless to set them after initialisation. The actual setting is done by overriding the set_property method of GObject. You can also ref/unref you parameters if necessary there.
The *_new method
The new method should just consist of one call to g_object_new(MY_TYPE, “foo”, foo, “bar”, bar, …, NULL). NEVER add anything else to this method!
The _init method
Here you can do as much initialisation work as you like. This method is called by the GObject system and thus will be accessed from all language bindings.
Why?
When wrapping a library it is lots of work and takes lots of time to convert every parameter to a construction property and to move all other initialisation code from _new to _init. Besides it is clean and everybody will start loving you…(and you would have saved me at least two hours today!)