Fortunately, Mozilla spent the last few years working on the same problems, and created some great tools and tutorials to get us started.

For example, this is a treemap we generated using a TraceMalloc snapshot and the JavaScript Information Visualization Toolkit, showing a simplified view of who allocated what:

Initially this view was just depressing. It looked like our only hope was to get rid of the XBL bindings, JavaScript, CSS, database engine and everything else that makes Songbird cool. Eventually, after many hours exploring memory allocation logs, we found areas that could be easily improved.

Here are some results:

Details: For this comparison we used a Windows XP SP2 machine with 1GB of RAM, and a library of 20,000 mp3s. By “Add-ons or Helpers” we mean the default add-ons for Songbird, the Winamp taskbar agent, iTunesHelper.exe, and WMP’s Media Guide.

And the winner is… Windows Media Player? Unexpected.

The point is we managed to reduce basic memory use with a large library by about 40%. Even more important, Songbird will no longer take all your RAM if you leave it playing for a week.

Specifically, we:

• Cut CPU usage during playback by half
• Fixed some serious playback memory leaks
• Drastically restricted database caching
• Tuned the media item property cache
• Added batching to the media importer, reducing memory use by 60%
• Reduced Mac download size 45% by stripping debug symbols (oops)
• Fixed minor memory leaks when switching feathers
• Extended our performance monitoring farm to track memory usage and prevent regressions

There is still a lot to do though, and we’ll continue to focus on memory and performance in the future. The iTunes importer, add-ons like mashTape, or lots of browser tabs significantly increase memory usage, and deleting a lot of tracks at once still takes a long, long time.

If you haven’t yet, please grab the latest 1.1 beta and give it a try. Let us know what is working, and what is still painful.

Closing Bug 14442 made it possible to fine-tune how much memory Songbird uses to load and display your library.

Up to this point Songbird has allowed SQLite to cache whatever it wants, meaning that over time your entire library database can end up in RAM.

We’re changing this with 1.1, and are in the process of coming up with some heuristics. If you’d like to help out, or want explicit control over SQLite memory usage, try the new preferences in a nightly build after January 30th.

dbradley, pvh, jacklu, kreeger and myself had a lot of fun working on performance problems that had been annoying us. Our goal was to improve basic every-day library management, and the results are a huge step forward.

Scrolling is much much smoother, searching is thousands of times faster, databases are 60% smaller, and importing is nearly twice as fast and many times more efficient. Songbird is much more pleasant to use, and can now easily handle 20,000+ track libraries. In fact, it seems to scale about as well as other popular players.

OBLIGATORY INFOPORN

This is (mostly) the output from a new performance lab that marcc and toks set up. Every night we get performance reports for the library API, allowing us to verify progress and avoid regressions. Don’t worry about the times, these are stress tests, not actual user use-cases. The lower the time, the better the performance.

Read on if you’re interested in how these improvements were made.

SCROLLING

The main library view is a XUL Tree widget, just like the bookmarks in Firefox and mail view in Thunderbird, so we were concerned that Songbird used nearly twice as much CPU and scrolled much more slowly than these applications. Simply moving the mouse in a circle over the tree would consume up to 80% CPU.

Profiling with Shark showed a lot of wasted effort reading item metadata and firing events while painting the tree. A little work to adjust how the selection is maintained and refactor the caching code significantly improved library scrolling.

Next was a paging hiccup every 1000 items when scrolling large libraries. Logging and timing queries showed that secondary sorting was to blame (first sort by artist, then by album, then by disc number and track number). Getting sorted media item IDs for 1000 rows could require hundreds of queries, each with a cost proportional to the library size.

Since secondary sorting is not user configurable we now pre-compute another sort value for each property. For example, when album metadata for a track changes, the secondary sort value for the artist property is rebuilt and indexed, making sorting by artist, album, disc, track number essentially free.

SEARCH + FILTERING

In 0.7 we moved to SQLite Full Text Search (FTS3), and found that in most cases it was extremely fast. Unfortunately though search time grew exponentially with the number of match results, and searching for “a” in large library could hang for up to 30 seconds. Lame.

Half of the problem was the secondary sorting issue that had been slowing down scrolling. Each query had to include the search and filter constraints, so a slight cost increase would be multiplied by 50 to 100x. Removing this multiplier helped a great deal.

The other half turned out to be the way we were joining the FTS3 table to the properties. Query optimization is mysterious, so testing and measurement are critical. Query logging, our performance test harness, and the SQLite ‘EXPLAIN QUERY PLAN’ command helped us determine that joining the FTS table, then the properties, then the media items is an order of magnitude faster than equivalent queries.

Finally, since library filter lists only show a small number of values, we now fetch all rows at once, removing the need for a separate count query of approximately the same cost.

Lessons learned:

• Table joining order is extremely important. As a rule, join the most restricting or most expensive to join table first. Whatever you do, test a few permutations.
• Joining with virtual and temporary tables prevents the use of an index for both joining and sorting. ‘EXPLAIN QUERY PLAN’ shows that an index can still help with a join, but sorting has to be done the hard way.
• Occasionally the query optimizer will make bad decisions, and forcing it to use a specific index can help quite a bit. Placing the unary plus operator (+) in front of a column name indicates that an index should not be used.

Recommended links:

• SQLite Query Optimizer Overview
• SQLite Optimization FAQ
• SQLite performance tuning and optimization on embedded systems

ADDING TRACKS

Importing large libraries was slow, and required an obscene amount of memory. With 1.0 it still isn’t ideal, but it’s fast, and the memory usage is 10% of what it was in 0.7. Some of the improvement came from the database changes described below, but significant progress was made simply by avoiding unnecessary work.

The first pass removed unnecessary code paths. 0.7 computed an MD5 hash for every track, doubling IO costs, and would frequently loop over and copy the list of tracks. This behaviour was redundant, and required a huge amount of memory when importing 50k+ tracks.

The second pass cleaned up library change listeners. Tracing with the DTrace JavaScript probes and profiling with Venkman revealed that the smart playlist system and album art scanner ignored batching hints. Batch notification was added after the initial listener API was created, and for backwards compatibility it is opt-in, making it easy to forget that a single JavaScript listener called 50,000 times can hang the UI. The listeners were fixed, but we need an API that is easier to use correctly.

DATABASE ENGINE

Experimenting with BloatView and Instruments, we established that the large library memory problems in 0.7 were mostly caused by our database engine.

Any time Songbird operates on a large set of media items (adding, deleting, enumerating) it builds multiple queries per item, enqueues them, and then executes them. In 0.7 these queries were constructed as strings, which, multiplied by a library of 50k+ tracks, could require hundreds of megabytes.

The problem was solved by adding prepared statement support to the database engine and library code. Now a single compiled query instance can be used with a large set of parameters, and the number of media items involved is barely a factor.

Discoveries along the way:

• NS_ProxyRelease should be treated with caution, since it can cause objects to pile up.
• A string query or prepared statement with a “column IN (?, ?, …)” clause is much faster than an equivalent set of “column = ?” prepared statements.
• The SQLite ‘ANALYZE’ command doesn’t need to be run all the time. Dump values from a typical database and include hardcoded results with the schema.

DATABASE SIZE

The easiest way to improve database performance is to just have less data. Seems obvious, but it’s easy to overlook.

In 0.7, a 10,000 track library required a 50MB database, of which 60% went to storing indices (according to the sqlite analyzer). Indices store a complete copy of the indexed data, and are expensive to maintain. They are also difficult to remove, as you have to be sure you wont hurt performance. Using ‘EXPLAIN QUERY PLAN’ to figure out which indices were used, and the performance test suite to avoid regressions, we dropped three indices for an overall size reduction of 40%.

We also noticed that many values were stored as UTF-16, despite never containing Unicode (since our generic property schema stores everything as strings). With a little experimentation we discovered that using UTF-8 databases did not impact performance, even for large libraries of entirely Unicode metadata.

Switching to UTF-8 gave another 40% reduction, and an average 10,000 track library in 1.0 is now 18MB.

UP NEXT

Where are the new pain points? If you’ve been using the 1.0 RC builds please let us know how things are working, and where you think we should focus. Songbird can never be “too fast” or “too lean” and we’re committed to improving performance in every release going forward.

Large library performance is a major theme this release, and the first few fixes are in: On my Mac Pro I’m seeing a 45% improvement over 0.7 when importing 10,000 tracks from a local folder.

The win came mostly from removing the boring/terrifying “Identifying and Removing Duplicates” phase of the media import process. This phase was added around 0.6 to protect finicky MTP devices, but didn’t turn out to be that important.

Don’t worry about being overwhelmed with duplicate files, there is always stevel’s The Exorcist add-on.

Next week, faster search?

If you are a developer and use sbIMetadataJobManager or sbIMetadataJob, you’ll need to update to the new sbIFileMetadataService.

Here is a quick summary for fellow metadata nerds:
 

FORMATS

Songbird uses TagLib 1.5 on all platforms to read from FLAC, Ogg Vorbis, MP3, M4A, MusePack, TrueAudio, and WavPack files. This includes all versions of ID3, APE, and Vorbis comments.

On Windows/Mac the QuickTime extension adds AMR, M4P, and M4B reading.

On Windows only, Windows Media Player adds WMA, WMV, ASF, ASX, and AVI reading support.

As of this release our TagLib wrapper also supports writing the following formats:

• MP3 – ID3v2.4, leaving existing ID3v1 as-is.
• FLAC – Vorbis comments, updating ID3 tags if they exist.
• MusePack – APE, updating ID3 tags if they exist.
• Ogg Vorbis – Vorbis comments.
• TrueAudio – ID3v2.4, updating ID3v1 tags if they exist.
• WavPack – APE and ID3v1.

Further support can be added with TagLib plugins, and the clunky but functional sbIMetadataHandler interface. At the moment there are open bugs to add Ogg FLAC, Speex, and M4A support.

Note that writing is currently disabled by default, and a prompt is shown on first edit. The plan is to enable writing by default in the final released build.
 

TAGS

Currently Songbird tries to write title, artist, album-artist, album, comment, lyrics, genre, producer, composer, conductor, lyricist, record label, language, key, license, license URL, year, track number, total tracks, disc number, total discs, and BPM tags.

Rather than add custom logic mapping Songbird properties to various metadata tags, Peter, aka pvh, has been working on enhancing the generic interface provided by TagLib. The new interface exposes all common tags, and leaves format specific handling to each implementation. Where possible, he’s been following the mappings used by PicardQt.

While this functionality is working quite well, there are a few peculiarities worth mentioning:

• The non-standard part of compilation flag is not yet supported (Bug 9090).
• Total tracks and total discs are not supported by some formats, and are being written as a single string of number/total.
• Songbird currently only supports one genre tag per item, where some formats support multiple.
• Play count and rating are not written by default, but may be available with a preference option (Bug 9084, 9236).
• Reading and writing album artwork is not yet supported (Bug 9033).
• Some properties cannot be unset at the moment (Bug 8530).
• The producer tag is not handled correctly in ID3v2 (Bug 9086).
• Lyrics and lyricist tags are not handle correctly in ID3v2 (Bug 9091).
• Comments are truncated in some cases when writing ID3v2 (Bug 9088).

EDITOR UI

This release will ship with a basic, but extensible, modal metadata editing dialog. To try it out, select some tracks, then press CTRL/CMD-E, or select Tools -> Metadata Editor from the main menu.

While a modal dialog is less than ideal for power users, it significantly reduces user experience complexity. If you are outraged by this decision, don’t worry, we’ll also be releasing an extension with a non-modal editor and display pane.

It is now much easier to overlay new functionality into the editor, so if there is something you’d like to see, stop by irc.mozilla.org#songbird. If time permits, we’ll add some additional panes such as an advanced property viewer, lyrics editor, and summary page.

Finally, yes, you’re right, nobody wants to edit tags by hand. Now that we have writing support and an extensible editor though, MusicBrainz support shouldn’t be too far off (Hint: gstofa in gst-plugins-bad).

We have a solstice present for developers: a 0.4 Extension Wizard Druid.

Getting started with extension development can be time consuming, so we’ve built a tool to let you skip past the first two hours. They are boring hours anyway. Now you can pick a title, enter your name, select some UI sample code, and start hacking. Eventually you’ll need to understand the details, but in the meantime you can still have fun.

Download the latest 0.4 release candidate, then install the Developer Tools Add-on. Once installed, select Tools -> Create Extension from the main menu.

Cheers!

We love all the feathers that have been coming in lately. Since the 0.3 pre-release lots of people have been customizing their birds, and the results have been pretty cool.

With 0.4 coming out though it’s time to make sure the existing feathers continue working. Fortunately not too much has changed, and updating is almost as easy as modifying the version compatibility metadata.

If you designed feathers for 0.3, take a look at our Updating to 0.4 HOWTO (Thanks to Pino for helping with this).

If you’d like to create new feathers for 0.4, grab the latest nightly and check out the developer center.

Bug 3687 (Nuke the titlebar, plzkthx) is finally fixed.

Thank you thank you thank you to Håkan Waara, Steven Michaud, Colin Barret, and Josh Aas. Their hard work has restored XULRunner support for chromeless translucent windows on OS X.

Tonight’s build should be much less embarrassing on both Mac and Linux. Look for custom window chrome and a miniplayer with nice curves. Mmmmmmm.

This means that porting existing Firefox extensions could be as easy as modifying install.rdf and chrome.manifest configuration files. If you give it a try, please stop in to irc.mozilla.org#songbird and let us know how it goes.

It also means that existing Songbird extensions may have to be updated. In particular, if you’ve written an extension that uses any menu other than Tools, we just broke it. Sorry, but it’s for the greater good. Onward and upward!

See Changeset 6808 for details.