• Add date information to all possible albums (Alex Lancaster)
• Improve GStreamer error handling (Tim-Philipp Muller)
• Don't crash when re-opening the Preferences dialog
• Clear the genre field when re-reading the disk

• Add date information to all possible albums (Alex Lancaster)
• Improve GStreamer error handling (Tim-Philipp Muller)
• Don't crash when re-opening the Preferences dialog
• Clear the genre field when re-reading the disk

A snipped from the first article in a series in The Guardian. It continues later:

The traveller must, of course, always be cautious of the overly broad generalisation. But I am an American, and a paucity of data does not stop me from making sweeping, vague, conceptual statements and, if necessary, following these statements up with troops.

NP: Neighbour Radio, Last.fm

• Added API: e_book_query_vcard_field_exists, e_vcard_get_attribute, e_vcard_get_param, e_vcard_attribute_remove_value, e_vcard_attribute_remove_param_value, e_data_book_view_notify_update_prefiltered_vcard
• Extended EContactPhoto structure to support remote photos
• Changed name parsing tables to avoid relocations
• Fix "all contacts" optimisations so it actually happens
• Increased performance and reduced memory usage of the default addressbook backend

Out of the thirty commits to the addressbook since since April, half were merged from the DBus port!

NP: Feedback, Jurassic 5

When I first ported of EDS to DBus, it didn't perform as fast as the original ORBit implementation. However when I dug out OProfile I discovered that the main bottle necks were deep in EDS itself, and DBus although in the profiles, wasn't anywhere near the top. We spent a few months optimising EDS-DBus (there was some serious low-hanging fruit) and by the time we'd done the obvious optimisations, EDS-DBus was faster than upstream EDS for the typical usage (running a book view, which happens every time you search in Evolution).

For some methods EDS-DBus was still slower than EDS, and getContacts() is a perfect example. This method takes a query, builds the set of contacts that match, and sends it back to the client in a single list (compared to book views that do the same thing incrementally, and provide future updates). When profiled you discover that libdbus and libc are the top offenders, taking almost 70% of the runtime. The benchmark was asking for all contacts, so EDS-DBus was sending a 150 contacts as vCards over the bus in a single list, which amounts to about 100Kb of data. Now, this gets copied when it enters the library, copied again as it enters the sockets to the bus, which then sends it into another socket to the client, which then makes a copy. These copies really hurt, and are one of the things that ORBit does better than DBus: it copies less frequently and has generally had more optimisation time. There are several ways of making it better.

• Those nice people at Collabora have batshit insane cunning plans for a SHM-based transport, instead of sockets. This would reduce the number of copies, but does introduce some, well, interesting locking fun.
• Almost half of the copies could be removed by creating a private connection between the client and the server, missing out the bus entirely. I plan on doing this for the book views as they are heavily used and the bottleneck is, again, the copies.
• Obviously, heavily profiling and optimising libdbus to remove any redundant copies would help. There may be cunning ways to avoid some of the copies for certain situations, and allowing those to happen in the GLib bindings would be useful.

In conclusion, the DBus vs ORBit performance issue isn't a real one generally. It's a rare case where the cost of the transport is the bottleneck (generally only in fake benchmarks), and when the transport is the bottleneck, there are generally other ways of optimising the code: as Havoc says DBus makes doing true asynchronous method calls trivial, and if you are sending huge amounts of data down the bus a private connection should be used (which will also make you a nicer citizen on the bus, as sending huge messages will clog up the tubes).

NP: Kind Of Blue, Miles Davis

Thus I've been thinking about selling the 28-135 and buying the 17-85mm IS USM, which is clearly targetted as being the 28-135 for cropped digital SLRs. I'll loose the extra zoom but in return gain the wide angle in a single lens. However, the optical quality of the 28-135 is excellent for a non-L lens, and I'm worried that the 17-85 isn't up to the same quality. Are there any really picky camera geeks out there who have used both the 28-135 and 17-85 and can help me decide?

NP: Prose Combat, MC Solaar

Oh well, I'm planning to get a pair of small speakers (MS Avant 902i are looking good) and one of those super-cheap Super-T amps for this room at some point.

NP: Ágætis Bryjun, Sigur Rós

Over time Evolution was refactored, split into Evolution and Evolution Data Server, and so on. Then BDB was statically linked into not only the addressbook backend but also libedataserver, which contains some generic caches based on BDB. Now BDB isn't exactly a small library (it adds ~600K to a .so), so the second static linking started to irritate people. Not only does EDS have a private copy of a library, meaning extra work when BDB has security bugs, but there is 1.2M of code that could be shared. This led to various distributions patching EDS to use a system copy of BDB, a patch that has finally made it upstream, but not everyone is using it: by default EDS uses it's private copy.

Now fast-forward to today. I did a full build of EDS from CVS using the system BDB (it's also a lot faster to build that way) and hit build failures from code demanding the static BDB to be built. Fixing these was trivial, but when I checked in the patch it worked fine... I investigated and discovered that BDB is now used in four places inside EDS:

• The addressbook "file" backend. This is the original user
• libedataserver
• The Groupwise backend, as a cache
• libedata-book, the server-side addressbook library

Now, BDB is approximately 600K when statically linked, and a typical EDS build statically links it four times. The server process will load both backends and both libraries, so it contains all four copies of BDB at once.

This is getting silly. Please, all packagers, if you support multiple versions of BDB in your distribution, use --with-libdb=/usr to dynamically link to BDB. As a fallback I'm about to create a patch that installed the private BDB into a private library directory, to avoid all of this static linking.

NP: Neighbour Radio, Last.fm (via Last Exit)

Now I've yet to update Evolution for the new API, so people doing builds from CVS will find they break. I'll try and get it fixed today, but I can't promise it. The fixes will be fairly simple if you ignore the new features, so someone else should be able to easily do it.

NP: Cool Groove

NP: Colour the Small One, Sia (via Last.fm)

NP: Neighbour Radio, Last.fm

Sputnik is a great little Internet radio player. The UI is heavily based on Muine, it uses Python and GStreamer, and pretty much Just Works. It's only up to version 0.0.3 but it's been my main source of music for the last few days, so it does what it needs to well. I'd like to see it displaying the song title and artist somewhere, but that is about it really.

NFlick is a Flickr set browser for the Nokia 770. As it is only version 0.1 is has some flaws: it eats huge amounts of memory (no running it at the same time as the web browser). crashes a fair bit, doesn't cache images, and doesn't support the hardware keys. However, when it works, it works well: this is just the sort of tool I want on the 770.

NP: Digitally Imported - Lounge

Next step: World Domination!

NP: This Is My Demo, Sway