This is the archive for February 2009. Recent posts can be found at the main blog page.

Bashing Bazaar again?

Wednesday, February 25, 2009 ★ 21:49 ★ Category Gnome ★ Permanent url

Dear Lennart,

It’s not my intention to start another flame war, but your blog post about bzr clearly shows that your real intention was not to obtain source code, but to bash bzr. I’ll explain why.

Simply visiting the the url http://www.mega-nerd.com/Bzr/libsndfile-pub/ with your web browser gives a 404 Not Found error message. That’s quite clear, so it’s not very likely there will be a branch there, right?

Spending a complete flame on your experiments with many different Bazaar commands, while the instruction page you linked to exactly tells you how to proceed, is not justified in my opinion. Especially not if you’re looking for help, and the very top of the bzr man page contains this:

SYNOPSIS
       bzr command [ command_options ]
       bzr help
       bzr help command

Yes, there’s help in there. And you also mention that in your own blog post, so there is no point in complaining about man pages, or trying the totally non-obvious man bzr-get and concluding that there is no help at all.

So, given that the url is dead (well, not found to be precise), how would you proceed from here? You’re tech-savvy, and you know how file systems work, and you probably know how the web works. So you could’ve tried visiting the parent url by cutting off the trailing part of the address. You would’ve ended up on http://www.mega-nerd.com/Bzr/, whichs contains a link to the right address that happens to work flawlessly:

$ bzr branch http://www.mega-nerd.com/Bzr/libsndfile-cue/
Branched 1046 revision(s).

The way you’ve written your blog post is highly insinuating and not helpful to anybody at all. You’ve written many very good blog posts in the past, so please keep it like that and refrain from spreading uninformed nonsense in the future. Thank you.

No love (well, not until you fix libsndfile…),

— Wouter

P.S. I’ll leave it to you to make the author of the instruction page aware of the incorrect url. You’re a good net citizen after all, aren’t you?

P.P.S. The in mano in your web page title should be in manu, since that is how manus is inflected in Latin.

MySQL last insert id performance issues

Wednesday, February 25, 2009 ★ 17:39 ★ Category Programming ★ Permanent url

After suffering from severe performance problems for a rather data intensive application (which was explicitly designed with scalability in mind), the culprit was found: a often executed piece of code did not execute SELECT LAST_INSERT_ID(), but SELECT LAST_INSERT_ID() FROM some_table. Hard to spot, but very important.

The problem? Well, the LAST_INSERT_ID (see the MySQL manual on LAST_INSERT_ID) function just returns the resulting primary key value from the last INSERT statement in the current MySQL connection thread, regardless of the table into which the row was inserted. Erroneously appending FROM some_table to this statement will result in a query that returns rows from a table, and these rows only contain the same constant value over and over again, once for each row in the table. However, if you only retrieve one row from the result set, you won’t initially notice the bug… at least not until your application mysteriously gets slower. If the table grows significantly over time, which was clearly the case here, since many records are inserted every day, executing this very simple query will become slower and slower, since it returns as many rows as are in the table, and each subsequent row yields exactly the same information as the previous one. How much slower? Well, up to the point that multiple quad core machines with plenty of memory were constantly suffering from such a high load that they became almost unresponsive. Yes, we were running this piece of code many times in parallel since it is supposed to be not CPU bound, but network latency bound.

The solution? Well, a very easy fix: after dropping the FROM some_table part from the query the load on the machines instantly dropped back to almost 0, which was how this applications was designed since it’s mostly network latency bound, which does not use much resources other than occupying some file descriptors for open sockets.

The lesson learnt here? A speed-up of many orders of magnitude, just by removing two words in the code… yes, sometimes performance optimization is completely in the nitty-gritty details. Unfortunately we had to find out the hard way.

(Yay for the person who found this. You know who you are.)

Fishy audio metadata

Saturday, February 14, 2009 ★ 19:48 ★ Category Misc ★ Permanent url

I’m delighted to find out that both FLAC and ID3v2 explicitly have support for the only picture type that really matters, namely that of a bright(ly) coloured fish. Both the ID3v2 specification (section 4.14) and the FLAC format specification (see METADATA_BLOCK_PICTURE) reserve picture type 0x11 for a picture of a fish. Though one can also embed pictures in Ogg/Vorbis, the Ogg Vorbis Comments specification does not explicitly list it, but to make up for this omission that page displays a colored fish (the Xiph logo) on the top of the page.

Is it just me, or is something fishy going on here?

Update: One of my gentle readers pointed out that it’s probably a red herring...