Planet Qt - Highlighting Qt development and applications

I thought, that I should write about this topic, because it’s time to start my self-education project again and see how I can take new features of Qt in use. I’m not sure how useful this blog post is because there already is a nice wiki page available about the same topic on qt-project.org. But for those, who [...]

With only roughly over five weeks to go, QtCS 2012 is approaching fast on the event horizon (pun absolutely intended). During the TiZen Developer Conference, Quim Gil and I, with help from Robin Burchell, found time to work on a draft, the result being visible in the QtDev wiki. Don’t be scared by the amount of pre-scheduled sessions, we will try to keep it as unconference-y as possible. However this allows us to properly prepare selected sessions.

Please keep in mind that QtCS 2012 is invite-only.

Session presenters, prepare!

If you are a maintainer of a Qt Essentials module, then you will have to drive one of the pre-scheduled sessions.

It might be a good idea to start writing a report about what happened in your area over the last couple of months, and where you plan to take your module for the Qt 5.1 release. Attendees of your session will probably expect you to talk about Qt 5 migration and how it will affect code using your module. On top of that, the most urgent bugs might get discussed, along with new feature requests, so please be prepared.

If you find a topic that isn’t showing up in the program yet, consider to get in touch with other interested folks (the Qt development mailing list or #qt IRC channel are good places to ask). With sufficient feedback, you should have everything it needs to drive the session yourself!

Plenary sessions

The first day will start with the State of the Union session about Qt 5 and Qt 5.1, summarizing where we are and where do we want to go with the Qt project.

The second day is about betting on Qt Quick, covering topics such as theming, platform integration and cross-platform. We want to invite the maintainers and a few vendors/users/contributors to expose their thoughts and needs with the hope of bringing a common understanding.

For the last day, we have a special surprise, as the topic will be HTML5 & the web. I am aware that this will raise a lot of controversy among the community, but it is an area where we need to find answers. With all the latest interest in web technologies, the answer can no longer be “We don’t do web”. That’s what killed the dinosaurs, remember? Then again, Qt already has better answers then that, so it’s about time for a fierce but honest panel discussion, including the Qt WebKit maintainers and other users/contributors driving this area.

Hack'n'Tell

Of course we also want to you to feel entertained during the summit, which is why we want to try out Hack'n'Tell sessions.

The rules are simple: Show us a cool hack involving Qt. You got 5 minutes. No slides.

I realize that preparing cool hacks takes some time, which is the original intent for this blog post: to announce the Call for Cute Hacks. For the first day at least, it would be great to have a couple of presenters before the summit starts. For the other days, I kind of hope that the summit itself will spark great ideas and demos that need to be shown immediately.

I hope I got you excited a bit, so let’s make QtCS 2012 an event to remember!

Permalink | Leave a comment  »

In QHeaderView there is admittedly a confusing concept of referring to the different header sections, they can be referred to by their logical index or by their visual index. And then when you start trying to use the functions to go from one to th...

A repeated problem we run into when using QMake is that it focuses on being a build tool, and because of that does not implement some features for executing parts of the project (like tests). Others ran into this issue as well, as for example this discussion of specifying run configurations from QMake on Qt DevNet indicates. Multi-part projects often consist of dynamic libraries that contain the features, and applications and tests that link this library. Amongst other things, this approach allows tests to link objects which contain the application’s code. Now when the tests are executed, the dynamic linker needs to be able to pick up the freshly built library and link the test with it at execution time. Projects usually run test cases with make test, and ideally the tests should execute out of the box after the sources have been configured and built (out of the box meaning that no tweaking of the environment variables should be needed between make and make test). After all, it should be as easy as possible for developers to execute tests.

This is also a problem in IDEs like Qt Creator, but also others – for every build configuration (having separate shadow build directories), the developer needs to configure the library path before being able to debug the application. This second problem needs to be fixed in the IDEs. For the first one – configuring test runs from the QMake .pro file – we have developed a solution called QMakeTestRunner that takes care of the problem. QMakeTestRunner assists in setting library paths when running unit tests in products built with QMake. It makes make test work out of the box right after makefiles have been generated. It is Free Software, published on Github, and small and easy to integrate into projects as a Git submodule. Much of this information will go into the documentation on Github as well.

Motivation, aka “The Problem”

QMake as a build system is simple and complete for building code, but it lacks a simple way to run unit tests dependent on libraries which are part of the project itself. In this case, paths which are created in the build directory need to be added to the dynamic linker library path before the tests can be executed. Especially with shadow builds, this would require manual setup, and make test would not work out of the box after QMake has been run.

QMakeTestRunner, aka “The Solution”

As soon as any target in a QMake project has the testcase attribute assigned to CONFIG, QMake automatically generates a target called check that runs this test. Unfortunately, make check does not allow the manipulation of the linker paths before running the tests either. QMakeTestRunner contains boilerplate code that wraps QMake’s make check target with a new one called make test, and through variables specified in the QMake file allows the specification of paths to be added to the linker path.

Usage

QMakeTestRunner is intended to be used as a git submodule to the main project. It should not require any modifications to be used. It requires Python to be in the path, checks for it, and the QMake run will fail if Python cannot be detected. When using other version control systems than Git, QMakeTestRunner should be small enough to simply be copied into the project as a subdirectory.

Project configuration example

The following example adds the directory libs/ in the project build directory to the linker path. It assumes the QMakeTestRunner repo is located under 3rdparty/QMakeTestRunner. The path where the dynamic library is generated in below the output (build) directory, which is why it is prefixed with OUT_PWD:

TEST_LIB_PATHS += $$OUT_PWD/libs
include( 3rdparty/QMakeTestRunner/testtarget.pri )

To trigger extra diagnostic output of the test runner, add

TEST_VERBOSE = 1

before including testtarget.pri.

make test

Once testtarget.pri has been included, a test target is defined in the makefiles. Simply run make test to execute the original make check with the necessary paths.

Mac OSX Frameworks

Frameworks on OSX are a different kind of library. The framework path is passed into the dynamic linker using a different environment variable. To specify a framework path, set the TEST_FRAMEWORK_PATHS variable before including testtarget.pri.

TEST_FRAMEWORK_PATHS += $$OUT_PWD/frameworks

Setting up QMakeTestRunner as a Git submodule

Using a Git submodule has the benefit that the code for the runner does not need to be duplicated into the repository of the project that is supposed to use it. It also makes it easy to pull updates to the test runner by simply updating the submodule to a new revision. To add the submodule as 3rdparty/QMakeTestRunner in your project, follow these steps:

> mkdir -p 3rdparty
> git submodule add git://github.com/AgileWorkersSoftware/QMakeTestRunner.git 3rdparty/QMakeTestRunner
> git submodule init

The directory 3rdparty/QMakeTestRunner should now contain the current revision of the test runner scripts.

License, contributions, issues and support

QMakeTestRunner is Free Software licensed under the GPL, version 3. Contributions to it are welcome, please propose them as Github pull requests. To submit a bug report or feature wish, please use the Github issue tracker for the project.

Commercial support for QMaketestRunner or general issues with QMake is provided by Agile Workers Software. We are happy to help.

Music Ally recently interviewed or very own Muesli (aka Christian Muehlhaeuser) about music, technology and Tomahawk. We've reposted the Q&A here here so you can get a little more insight into our fearless leader, his background and where we are going.

1. Can you tell me about one of your favourite webs projects you’ve worked on and why? 

While I technically never really worked on Last.fm's website - I was busy working on their desktop apps - I probably still have to go with that project. I had joined the company fairly early, before the entire Web 2.0 craze kicked in, and it was astonishing to see how our fairly small team handled everything as it grew. Back then we were only five or six people - and almost four years later, when I left, we had over 20 million users and more than 120 people were sitting in the office. In that short time, we had pretty much experienced every startup scenario you could imagine: from camping and living in the office, learning how to scale and deal with our growing userbase, dealing with the fear of surviving as a startup, taking on investors, introducing major design changes that caused user uproar, to eventually selling the company. It was always a bit of a rollercoaster ride and I probably learned more in those 4 years than in all my other projects combined. 

2. What have been the main challenges with developing the Tomahawk player? 

Tomahawk is a bit of a swiss army knife. It's fairly easy to build a client / server system where you control both ends, but we don't with Tomahawk. It's a music player that aims to bring all the various scattered music silos and experiences (across the globe) together under one roof... and then enhance the user experience (social, dynamic programming, discovery, etc.) across the top of it all. You can build playlists and add tracks not only from your local collection, but also from Spotify, YouTube, SoundCloud, Official.fm, Jamendo, your remote and online music collections, and many more. The hardest challenge is to support this variety of different APIs and bringing them together in one coherent, consistent user interface. You shouldn't have to jump from one music service's interface to another's just because you want to listen to a different song - just like tuning in to another radio station or TV channel doesn't require you to turn on a different device either. We see the need for that one place where you can listen to anything from Lady Gaga to your cousin's punk band - in one seamless interface. 

3. What do you think will be the trends in the next breed of music services?

As the debate continues to grow about online streaming royalty payouts, I unfortunately think we will see a reverse trend of more content fragmentation as bigger artists pull out of some services and potentially sign more lucrative exclusives with others. Similarly, I think there will be more niche services that aim not to license the entirety of recorded music, but just small subsets of genres and artists. We believe that both of these trends will further necessitate solutions like Tomahawk to fill those holes in one service's catalog from other available sources. The only one that has the real ability to access all of the content a specific users wants is that user. This is fundamental to our approach that a user brings all the content they care about, from everywhere they have access to it, into a player that can just do the right things with it. 

4. What can be done to make innovation in music easier for developers? I really believe that music already is one of the most innovative spaces on the web right now. Many projects and companies exist and support open standards. The Echo Nest, Musicbrainz and Last.fm let you access not only your own data, but you're pretty much free to play with all their data, too. Compared to books, movies and even TV - we're light years ahead. On the other hand, licensing content is probably still the biggest issue for new music platforms. As a startup with a small userbase and limited financial backing it's pretty much impossible to reach a licensing agreement with one of the majors, let alone all of them. I wonder how many brilliant ideas will never see the light of day because of developers getting frustrated by the process. Tomahawk tries to tackle this problem by letting developers play with the (free) meta-data and then bringing the content to the table from other services that their users already have access to. Your project shouldn't have to stream a song to me (and then pay for it) if I've already bought the track on iTunes - just play it from my disk. Not only is Tomahawk open-source, but it also has APIs that already let other projects and hacks leverage its content resolution. For example, the core team recently built Toma.hk (a website for sharing music across services and territories) using these APIs. Others have built things that let you scrape playlist metadata from loads of websites and then play them back using Tomahawk (and the content user has available) and someone just started to catalog all of John Peel's record collection as Tomahawk links. All this depends on open standards and data portability though, so I can't emphasize enough how important they really are. We believe that a user should own all their data (e.g. playlists) and be able to easily take them or share them across services. We hope this is a value that will be be adopted by all of the other players in the ecosystem as well. 

5. Tell us about a digital tool, platform, website or service you really admire from a technical perspective and why? 

There's a lot to admire out there: people built platforms that can deal with more than 25.000 tweets, 8.000 status updates and 800 scrobbles - PER SECOND - and we expect them to run day and night without a hiccup. Anyone who has worked on such a service or website knows how to admire something that most people take for granted nowadays. It's a lot of blood, sweat and tears.

Extra Credit: What's the story behind the name "Tomahawk"?

A tomahawk is a universal tool - one that can be used as a hammer, a knife, an axe. It was often the one and only tool you'd carry around. Given the great utility of such a tool, we felt the name seemed to embody what we strive to provide.

The Qt Creator 2.5.0 final has been released! There are lots of new features and improvements in this release, I’ll highlight a few here, some others are probably already mentioned in our beta blog post, and you’ll find a more complete list in our changes file.

So, new features and improvements include but are not limited to:

• You can repeat a recent search with the same parameters with a simple click on “Search Again”
• “Execute” Locator filter lets you run arbitrary commands in a shell from Qt Creator (“! <some command>”) (thanks to Yuchen Deng!)
• Experimental plugin that shows “TODO” items from your sources (thanks to Dmitry Savchenko and Vasiliy Sorokin!)
• Experimental plugin for autotools based projects (thanks to Patricia Santana Cruz and Openismus GmbH!)
• Mac OS X Lion users will we happy to know that QTCREATORBUG-6222 which prevented adding some Qt Versions has finally been fixed
• A very basic version of a C++ refactoring action that adds an #include for an unknown identifier has been added (move cursor on identifier, press Alt+Return (Option+Return on Mac OS X))
• A very basic version of a C++ “extract method” refactoring action
• Improved support of C++11 (nullptr, constexpr, static_assert, noexcept, inline namespaces, auto, lambdas)
• Rearrange C++ method arguments (thanks to Bojan Petrovic!)
• New hints and warnings for QML code, including an option to prevent them for specific lines (with a special comment)

Note for Windows MinGW Users

We decided to remove the custom MinGW distribution and MinGW gdb from our Qt Creator-only Windows binary distribution package. The original reasons to include it there (it was the predecessor of the Qt SDK) are since a while now filled by the Qt SDK. Also, updating the shipped version is a legal hassle as long as the binaries are provided through Nokia, but we also don’t want to ship stone age versions. We are working on build infrastructure for the Qt Project itself though, that we ultimately want to use to build Qt Creator packages, snapshots, and more. Currently, on http://builds.qt-project.org, you find Qt Creator snapshots for Linux and Windows, and also a Python enabled MinGW gdb (that reportedly doesn’t work on Windows XP). It’s still possible to install MinGW and gdb separately and register them in Qt Creator. We are not removing the support for it from Qt Creator.

Previously shipped MinGW: ftp://ftp.qt.nokia.com/misc/MinGW-gcc440_1.zip
Previously shipped MinGW gdb: ftp://ftp.qt.nokia.com/misc/gdb/7.2/qtcreator-gdb-7.2-mingw-x86.zip

Up to date MinGW: http://www.mingw.org (we might provide a compact version like the one in the old installer later)
Python enabled MinGW gdb 7.4: http://builds.qt-project.org/job/gdb-windows/ (compiled on Windows 7, doesn’t work on Windows XP)

Thanks to All Contributors

Too many to include them all here, please scroll to the end of our changes file!

Download

See our Release Page

Qt Commercial customers have a great advantage to safely compile Qt statically and create their own static libraries and applications. Here, I have gathered some practicalities related to working with statically-linked Qt. Hopefully, this provides...

Last sunday, we finished our week-long Swift Hackathon, and it was a great success, leading to Swift 2.0-beta1! Here’s a list of the things we achieved during that week.

First of all, the goal of the week was to find and fix as many bugs as possible. This is what our ‘hackathon bug count dials’ were displaying at the end of the week:

In only one week, we found 19 bugs, and fixed 64! Not a bad result for our first hackathon, don’t you think? As you can see from the trend, we put a big dent in the list of open bugs:

And if fixing all these bugs wasn’t enough, we found the time to do some other things on the side as well during the week:

• Together with Olly Betts, we finished our Debian packages, and submitted them to Debian. So, expect both Swift and Swiften to be available from the official Debian repositories soon!
• We set up a build for the brand new Ubuntu 12.04 (Precise Pangolin)
• We started fixing and cleaning up translation strings

Thanks again to all the people who have helped us during this excellent week!

After another year of development, we’re happy to announce that we released our first Swift 2.0 beta! We encourage everyone who is interested in helping us with testing to try out this new release, as it has many bugfixes and enhancements (see the release notes for more details).

Thanks to the hackathon week (of which details will be posted shortly), we believe this first beta to be pretty stable. Nevertheless, should you find some bugs, please come and tell us about it!

This webcast describes HTML5 and how it can be used to develop applications, both on its own and with the Qt toolkit.
View Online Download Download

Dear MkS users.
MkS team is proud to announce the availability of the Monkey Studio IDE 1.9.0.2.
This is a bug fixe release for the 1.9.0.0 version.
A list of the new improvements and some screenshots can be found here.
You can grab your copy of the new version from here.
Or, from your package manager if you are on Gnu/Linux/Unix like.

We hope you benefit from the new version.
MkS Team.

We’re just halfway through our Swift Hackathon, so we thought we'ld update you about the progress we’ve made so far. In fact, a screenshot of our live hackathon week bug counter sums this up quite well:

That’s right: in merely a couple of days, we managed to fix 50 (more than half!) of the open bugs, and found 17 new bugs. And what’s more: we still have the whole weekend ahead of us, so you still have a chance to join us in fixing, testing, and improving Swift!

A big thank you to all the people who have been helping us out so far!

The second edition of the Qt Contributors Summit is warming up. Venue and dates are secured: June 21-23 in Berlin. Some sponsors have already stepped in and more will come. The schedule is being discussed as we speak but in any case it’s all about technical sessions based on status sharing, planning and discussion. It’s the first big event organized in full Qt Project mode! We are working hard to offer the best context for up to 225 contributors taking Qt 5 to the next level.

Registration is open with more than 50 participants confirmed. Maintainers, approvers, contributors of code and other species are welcome. All maintainers are expected to be there or nominate a substitute for their module. If you meet the participation criteria you are welcome to apply as soon as possible. Note that this is an invitation-only event: please wait our confirmation before booking your trip.

We aim to have a modest budget for sponsoring travel expenses in special cases.  If you are in this situation you must apply for an invitation right now, so we can budget properly.

The budget of the event is entirely covered with the funds from kind sponsors. Nokia, Research In Motion, Digia, ICS, Intel, Froglogic, e-GITS and KDAB have already stepped in, and we are in conversations with more. Nokia and RIM are sharing the XL sponsorship package, a new precedent reflecting the new possibilities of the Qt Project. The deadline for accepting new sponsors is May 18. After that we will start producing the printed materials. In addition to the sponsorship benefits, all sponsors get real-time access to the accounts of the event and voice for suggestions on how to do better.

We are planning to combine some plenary sessions defined in advance with a grid of parallel sessions, most of them scheduled ad-hoc in pure unconference style. The plan is to focus on technical planning and collaboration between the developers of Qt, giving a secondary role (or no role) to unilateral presentations, marketing & outreach. There is still a lot of work to do! If you want to get involved meet us in the Qt Project [Marketing] list.

In QML, it’s so easy to use properties of components directly, and it’s even the way most examples do it. But here’s my quesion: If we consider this the wrong approach in C++, isn’t it wrong in QML as well? The answer is usually yes.

Here, I’ll show you how I think the best practice of building QML components is. It seems so simple, maybe even trivial. But I have met a lot of code that doesn’t follow it, and seen the problems that follow. QML is still so new, that best practice isn’t common knowledge. And in many cases, best practice haven’t even been discovered yet.

Let me give a quick example that shows the problem: You have created a Button component with all the bells and whistles such a component needs. You chose to build it using a Rectangle, so the border is handled by an existing component. Reuse is always a good and popular choice.

Here is some of the code of how the Button could be done:

Button.qml:
Rectangle {
    id: button
    border.width: 1
    signal clicked()
    property alias text: buttonText.text
    Text {
        id: buttonText
        anchors.centerIn: parent
    }
    ...
}

You now declare a Button, set the size and the text, and that’s it. However, you might also want to have a different border, so this is what we do in the UI QML file:

Ui.qml:
Rectangle {
    width: 360
    height: 360
    Button {
        anchors.centerIn: parent
        text: "Hello World"
        width: 100
        height: 30
        border.width: 2
        border.color: "blue"
    }
    ...

Now, here’s the problem: If you decide to expand the Button with other choices of how it can look, you will have a problem. For example, you might want to offer a BorderImage for the way the Button looks. But with the current use of a Rectangle, you can’t do this without modifying the code that uses this Button.

This is exactly the problem encapsulation solves: It allows you to make local changes to your component without modifying all the code that uses it.

The simple solution of the Button is to make it an Item that has a Rectangle. In OO terms, this changes from inheritance to aggregation.

My solution for creating QML components is to nearly always base them on Item, and expose whatever properties I want. The interface to my components is the sum of properties, functions and signals. How I choose to implement the component itself is an implementation detail, and should not be available to other components.

For a simple example, suppose we have a system where a bunch of Text items should always follow a shared style. If the style changes, all text must follow. In fact, the only thing the users of the text item can set, is the text itself.

This could clearly be done with Text directly:

StyledText.qml:
Text {
    // Event handlers to set the Style parts here:
    ...
}

This a valid choice, we simply need to tell ourselves that we shouldn’t set the color, size etc. directly, but allow the central style code to set it. And this is of course doomed. Some day, we hire a new coder, or forget ourselves. Whatever the reason, we will break the rules.

The proper solution is to encapsulate the component and hide the implementation behind the Item:

StyledText.qml:
Item {
    property alias text: textItem.text
    Text {
        anchors.fill: parent
        // Event handlers to set the Style parts here:
        ...
    }
}

It seems so simple, but I have seen a bunch of QML code that doesn’t do this. Every time you start modifying the code of components, you wonder what you break. And this only becomes much more valuable with real components that have much more complexity than the simple example code I have here.

If you follow this pattern instead, you will create robust and encapsulated components with no properties accessible by accident.

It's a common design to use full text search engines only for free text searches, but to store the actual structured data in a separate database. Such designs come at a cost. Therefore Openismus asked me to build upon my previous post, where I analyzed several FTS engines. This time I'll research if we could use the full text search index itself as our primary data store.

Relations

A first obvious limitation is the lack of joins. So to use the FTS index as data store, you must denormalize your data. That is, instead of storing your movie database in distinct entity tables like Movie and Artist, linked by relationship tables like isLeadActor or isDirector, you must find a way to put everything into one single flat table. This isn't entirely nice in terms of redundancy and consistency. On the other hand joining tables is what makes relational databases slow and hinders distributing them across servers. Is there someone whispering "NoSQL"? Well. Yes, while I absolutely dislike their striking marketing: They are on to something, and with our journey today we enter their land.

Seems I've lost myself in chatting, so back on topic. So to store data in a FTS index we must denormalize our data. Luckily they make it easier than it sounds. In opposition to the relational model, there is no need to create complex relationships, just to assign more than only one actor or director to a movie: When adding artists to your movie you just tag each name with the proper field prefix before adding it to the index, and you are done. FTS engines natively support multi-value fields!

With some additional effort it also should be possible to store more structured data in those multi-value fields, things like (release-date, country), or (actor, role): You'd add more prefixes and use the positional information stored for phrase searches to reliably identify those fields. Sadly my time is too limited to research this more in detail, but the Internet surely has documents about this. Well, or for additional fun you can try to figure it out yourself.

Exact Matches

Now a match reported by an FTS engine only tells us that the document or the chosen field contains the phrase we were looking for. When searching for `title:"The Matrix"` any FTS engine will not only return the first movie of the Wachowskis' triology, it also will give matches for the other two movies, and works like *"Making 'The Matrix'"*. So for doing exact lookups we'll have to filter the initial result, and drop any document that doesn't exactly match our requirements. Sadly we really must check the field value instead of just checking the computed score: For instance with Lucene both *"The Matrix"* and *"Making 'The Matrix'"* will get a score of 100%, since both documents fully satisfy all terms of the query. Also we cannot use the score as indicator to only check fields for documents that got at least 100%: When searching for `director:"Quentin Tarantino"` the movie *"Inglourious Basterds"* will get less than 100%, since Tarantino was working with Eli Roth for this movie. So this additional filtering sounds expensive at the first moment, but remember that our index lookup dramatically reduced the data set already. When looking for `title:"The Matrix"` in the *imdb-50* data set, we talk about checking 9 documents instead of 121,587 documents for example. For useful data sets we won't notice the overhead, like the test results below are showing.

You can just add unanalyzed fields and use term queries on them like kamstrup pointed out.

Data Types

So we've learned that lack of relations isn't much of a problem for many useful datasets, but structured data is not only about relationships, it also is about data types. Full Text Search engines only support lexicographical order, so they surely fail for dates and numbers. You surely cannot use them to find documents within a given range!

I am sorry to disappoint you. The people researching FTS are smarter than that. Actually properly sorting and ranging dates, while only using lexicographic order is trivial. Most probably you have done it yourself already. Simply store your dates in ISO format, that is YYYY-MM-DDThh:mm:ss.SSSNNN or any prefix of this, and you are done. Omit the separators if you prefer. ISO-8601 explicitly is designed for lexicographic sorting.

So how do you do this with numbers? You could prefix them, for instance with zeros, to get a fixed width. This works reasonably if you know your number ranges, and in most cases you do. Sometimes you know the range from your application's context, e.g. the first known celluloid film was recorded in 1888. More easily you just use your technical limits, like [-2⁶³..2⁶³-1] for long integers. While first experiments really followed that approach, padding numbers with up to 18 zeros isn't exactly efficient or pretty. Also we didn't talk about floating point numbers yet. Therefore FTS engines like Lucene or Xapian provide more efficient mechanisms for turning numbers into sortable strings. First they write a prefix indicating number precision (64 bit, 32 bit, 10 bit, ...). Then they convert the numbers to some unsigned format, and apply some kind of base-128 encoding to the resulting bytes. The most significant bit gets stored first. For floating point numbers they shuffle some bits of the number's IEEE-754 representation. The resulting, sortable 64 bit integer then is encoded like any other number. You can consult Lucene's documentation, and the source code of Lucene::NumericUtils, or Xapian::sortable_serialise for details.

Benchmarks

Hope I didn't lose you with all this theory, now it is benchmark time!

To test how useful FTS engines are for storing arbitrary data I've extended my previous benchmark to better support range searches, and to support exact matching of fields. I've also added Michal Hruby's patch for supporting prefix searches. Since the prefix search gives countless hits, the query results consistently are limited to 10.000 rows now. I've dropped QtCLucene for now since it doesn't seem to support numeric range searches and such. It was forked from Java Lucene a long time ago. For SQLite I ran two sets of tests: bm_sqlite doesn't create indices for fields like movie title or artist names. Since such setup is unfair when comparing with FTS engines, the second set bm_sqlite_index creates indices for all fields we perform lookups for. For tracker we again test the Nepomok media ontology (bm_tracker) and a optimized ontology (bm_tracker_flat), that attaches all properties to the same RDF class. I had to disable prefix searches for bm_tracker: The query ran for more than 2 hours on the dataset with 17k movies. I seriously wish I'd get sponsored to improve Tracker's data model!

Source code still is in the fts-benchmark repository, tagged as release/0.3.

Results and Discussion

Each query got run 7 times on 5 different data sets. This time I didn't take the mean of the query execution times. The individual results of each dataset are grouped together and labeled with qxx_t1 to qxx_t7. Data and result sets grow with each group.

Also be careful when reading the charts as time is scaled logarithmically. You might want to consult the raw data tables below for details. Please keep in mind that the basic goal of this benchmarks is to test scalability, not raw performance. Therefore I don't mind much if an engine is 10 times slower than another for small data sets. Constant performance is the ideal result.

You'll also notice that some charts have gaps for bm_tracker. Like explained above I had to skip bm_tracker for few data sets, as tracker took way to long to perform those benchmarks.

Lucene++ appears significantly slower than its competition for small data sets, but then gives comparable results for data sets with more than 3,000 movies. Still I would not overrate this finding: We are talking about lookup times in the range of 10 ms. That's still pretty fast and close to measurement limits like the spikes in the other engine's results show.

This results are similar to the rating:[90 TO 99] query.

For this query you see the importance of having an index for your lookup keys: Performance of bm_lucene++ and bm_sqlite_index remains almost constant, while effort of the other engines grows dramatically as the data size grows.

Xapian's bad performance comes as a surprise, but actually I am to blame here: For stupid reasons I've implemented this very search as range search in Lucene++ and Xapian (release:[1999/03/31 TO 1999/03/31]). As the results indicate Lucene++ seems to putting more effort into optimizing range searches, and compensates my mistake.

Similar results as for release=1999/03/31, only that Xapian behaves as expected now. When given a proper query it also shows constant lookup time for exact phrase searches.

With this query you see the advantage you get from using denormalized tables: Lucene++ and Xapian just are as efficient as in the previous tests, but as a not so big surprise Tracker with the flat ontology now beats all remaining engines, including bm_sqlite_index.

Performance of the different engines is similar to each other when performing prefix searches.

Raw Result Data

	rating:[90 TO 99] - 9 movies, 3 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	12.333 ms	10.409 ms	9.885 ms	9.821 ms	10.221 ms	9.840 ms	9.986 ms
bm_sqlite	0.196 ms	0.169 ms	0.169 ms	0.173 ms	0.166 ms	0.167 ms	0.167 ms
bm_sqlite_index	0.207 ms	0.183 ms	0.172 ms	0.192 ms	0.193 ms	0.173 ms	0.172 ms
bm_tracker	0.992 ms	0.655 ms	0.582 ms	0.589 ms	0.554 ms	0.549 ms	0.525 ms
bm_tracker_flat	0.693 ms	0.463 ms	0.437 ms	0.461 ms	0.450 ms	0.443 ms	0.436 ms
bm_xapian	0.242 ms	0.201 ms	0.200 ms	0.198 ms	0.200 ms	0.199 ms	0.197 ms
	rating:[90 TO 99] - 1,099 movies, 17 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	12.949 ms	13.057 ms	12.981 ms	13.018 ms	13.150 ms	12.840 ms	12.644 ms
bm_sqlite	0.696 ms	0.546 ms	0.516 ms	0.530 ms	0.515 ms	0.518 ms	0.522 ms
bm_sqlite_index	0.448 ms	0.234 ms	0.231 ms	0.237 ms	0.236 ms	0.231 ms	0.231 ms
bm_tracker	5.051 ms	4.485 ms	4.441 ms	4.486 ms	4.425 ms	4.831 ms	4.828 ms
bm_tracker_flat	1.465 ms	1.133 ms	1.110 ms	1.104 ms	1.108 ms	1.108 ms	1.108 ms
bm_xapian	1.445 ms	1.285 ms	1.159 ms	7.824 ms	1.878 ms	1.669 ms	1.393 ms
	rating:[90 TO 99] - 3,216 movies, 35 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	14.287 ms	13.596 ms	13.453 ms	13.912 ms	13.875 ms	14.559 ms	13.981 ms
bm_sqlite	3.524 ms	4.110 ms	4.129 ms	1.916 ms	1.732 ms	2.300 ms	9.584 ms
bm_sqlite_index	0.423 ms	2.036 ms	4.617 ms	4.577 ms	0.388 ms	1.957 ms	7.981 ms
bm_tracker	12.776 ms	11.816 ms	12.449 ms	11.755 ms	11.762 ms	11.983 ms	11.764 ms
bm_tracker_flat	2.935 ms	2.517 ms	2.374 ms	2.264 ms	2.250 ms	2.261 ms	2.258 ms
bm_xapian	9.292 ms	2.702 ms	10.573 ms	6.773 ms	3.098 ms	11.438 ms	3.035 ms
	rating:[90 TO 99] - 17,251 movies, 260 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	58.996 ms	56.894 ms	62.172 ms	57.028 ms	57.255 ms	57.540 ms	57.259 ms
bm_sqlite	36.682 ms	28.260 ms	34.116 ms	34.786 ms	35.195 ms	35.813 ms	35.221 ms
bm_sqlite_index	45.802 ms	62.460 ms	31.603 ms	32.982 ms	33.302 ms	31.904 ms	31.656 ms
bm_tracker	67.022 ms	64.609 ms	64.649 ms	65.243 ms	64.183 ms	64.887 ms	64.283 ms
bm_tracker_flat	14.730 ms	14.179 ms	14.132 ms	14.221 ms	14.248 ms	20.225 ms	35.888 ms
bm_xapian	94.872 ms	47.067 ms	85.202 ms	28.575 ms	142.854 ms	48.562 ms	52.567 ms
	rating:[90 TO 99] - 121,587 movies, 1,510 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	283.122 ms	392.801 ms	382.164 ms	403.929 ms	384.512 ms	408.292 ms	361.548 ms
bm_sqlite	293.488 ms	236.636 ms	249.677 ms	232.674 ms	270.198 ms	282.806 ms	218.726 ms
bm_sqlite_index	231.638 ms	311.523 ms	198.781 ms	279.063 ms	219.294 ms	192.589 ms	276.822 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	181.478 ms	272.453 ms	251.730 ms	256.744 ms	293.067 ms	230.615 ms	245.113 ms
bm_xapian	376.176 ms	417.637 ms	411.263 ms	366.596 ms	393.168 ms	372.888 ms	412.411 ms
	release:[1999/01/01 TO 1999/09/30] - 9 movies, 2 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	18.768 ms	10.167 ms	10.799 ms	10.215 ms	10.443 ms	10.917 ms	10.210 ms
bm_sqlite	0.165 ms	0.166 ms	0.164 ms	0.164 ms	0.168 ms	0.164 ms	0.164 ms
bm_sqlite_index	0.175 ms	0.175 ms	0.170 ms	0.169 ms	0.169 ms	0.169 ms	0.170 ms
bm_tracker	1.074 ms	0.569 ms	0.546 ms	0.561 ms	0.544 ms	0.549 ms	0.546 ms
bm_tracker_flat	0.877 ms	0.480 ms	0.460 ms	0.458 ms	0.461 ms	0.458 ms	0.456 ms
bm_xapian	0.183 ms	0.175 ms	0.175 ms	0.178 ms	0.178 ms	0.180 ms	0.175 ms
	release:[1999/01/01 TO 1999/09/30] - 1,099 movies, 34 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	19.154 ms	19.449 ms	18.811 ms	19.419 ms	19.692 ms	19.315 ms	18.862 ms
bm_sqlite	0.691 ms	0.686 ms	0.684 ms	0.687 ms	0.690 ms	0.702 ms	0.698 ms
bm_sqlite_index	0.365 ms	0.311 ms	0.317 ms	0.312 ms	0.311 ms	0.312 ms	0.313 ms
bm_tracker	6.231 ms	5.543 ms	5.734 ms	5.522 ms	5.663 ms	5.538 ms	5.465 ms
bm_tracker_flat	1.998 ms	1.494 ms	1.466 ms	1.469 ms	1.470 ms	1.454 ms	1.469 ms
bm_xapian	5.336 ms	1.590 ms	7.241 ms	1.977 ms	2.651 ms	4.013 ms	2.544 ms
	release:[1999/01/01 TO 1999/09/30] - 3,216 movies, 84 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	32.202 ms	31.513 ms	31.362 ms	30.894 ms	31.345 ms	31.741 ms	31.518 ms
bm_sqlite	6.169 ms	2.645 ms	7.560 ms	20.764 ms	10.385 ms	13.278 ms	10.206 ms
bm_sqlite_index	19.176 ms	4.358 ms	12.576 ms	15.448 ms	15.745 ms	5.572 ms	5.770 ms
bm_tracker	15.507 ms	14.803 ms	13.629 ms	15.465 ms	13.930 ms	14.515 ms	13.652 ms
bm_tracker_flat	3.956 ms	3.488 ms	3.183 ms	3.176 ms	3.213 ms	3.193 ms	3.157 ms
bm_xapian	18.414 ms	5.874 ms	11.902 ms	12.932 ms	19.995 ms	21.098 ms	13.009 ms
	release:[1999/01/01 TO 1999/09/30] - 17,251 movies, 374 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	93.892 ms	93.900 ms	93.549 ms	93.555 ms	93.924 ms	94.396 ms	93.795 ms
bm_sqlite	37.831 ms	44.905 ms	47.617 ms	45.894 ms	43.796 ms	45.752 ms	47.048 ms
bm_sqlite_index	48.475 ms	47.805 ms	43.046 ms	47.393 ms	44.689 ms	47.842 ms	54.208 ms
bm_tracker	72.507 ms	72.667 ms	72.233 ms	73.570 ms	72.997 ms	72.991 ms	72.527 ms
bm_tracker_flat	29.351 ms	48.892 ms	55.351 ms	49.793 ms	88.375 ms	55.393 ms	45.917 ms
bm_xapian	59.522 ms	168.591 ms	55.750 ms	83.424 ms	113.679 ms	62.803 ms	127.895 ms
	release:[1999/01/01 TO 1999/09/30] - 121,587 movies, 2,265 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	543.495 ms	564.582 ms	609.045 ms	519.248 ms	561.844 ms	663.549 ms	590.518 ms
bm_sqlite	165.617 ms	387.256 ms	293.285 ms	335.219 ms	324.528 ms	324.022 ms	371.839 ms
bm_sqlite_index	375.504 ms	315.671 ms	321.115 ms	371.228 ms	300.951 ms	344.073 ms	356.366 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	241.569 ms	316.626 ms	398.308 ms	349.426 ms	398.289 ms	318.078 ms	363.809 ms
bm_xapian	529.377 ms	556.989 ms	577.643 ms	576.194 ms	626.388 ms	545.251 ms	570.695 ms
	release=1999/03/31 - 9 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	10.065 ms	10.068 ms	9.702 ms	9.974 ms	9.837 ms	9.751 ms	10.356 ms
bm_sqlite	0.164 ms	0.165 ms	0.171 ms	0.168 ms	0.167 ms	0.164 ms	0.162 ms
bm_sqlite_index	0.171 ms	0.169 ms	0.171 ms	0.172 ms	0.175 ms	0.165 ms	0.164 ms
bm_tracker	0.659 ms	0.476 ms	0.473 ms	0.469 ms	0.464 ms	0.468 ms	0.468 ms
bm_tracker_flat	0.510 ms	0.395 ms	0.385 ms	0.384 ms	0.389 ms	0.383 ms	0.389 ms
bm_xapian	0.154 ms	0.152 ms	0.151 ms	0.153 ms	0.152 ms	0.156 ms	0.152 ms
	release=1999/03/31 - 1,099 movies, 2 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	10.853 ms	10.545 ms	10.718 ms	10.390 ms	10.521 ms	10.754 ms	10.661 ms
bm_sqlite	0.515 ms	0.528 ms	0.505 ms	0.512 ms	0.502 ms	0.507 ms	0.505 ms
bm_sqlite_index	3.139 ms	0.184 ms	0.175 ms	3.440 ms	0.183 ms	0.212 ms	0.205 ms
bm_tracker	4.559 ms	4.229 ms	4.177 ms	4.220 ms	4.383 ms	4.532 ms	4.464 ms
bm_tracker_flat	0.977 ms	0.830 ms	0.800 ms	0.808 ms	0.802 ms	0.811 ms	0.802 ms
bm_xapian	0.672 ms	0.685 ms	0.774 ms	0.752 ms	0.916 ms	1.285 ms	0.663 ms
	release=1999/03/31 - 3,216 movies, 2 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	10.799 ms	10.762 ms	11.399 ms	10.676 ms	10.704 ms	10.169 ms	10.325 ms
bm_sqlite	1.912 ms	1.462 ms	1.453 ms	1.163 ms	1.151 ms	1.157 ms	4.858 ms
bm_sqlite_index	0.366 ms	0.350 ms	0.355 ms	1.883 ms	0.364 ms	0.345 ms	0.371 ms
bm_tracker	11.707 ms	11.548 ms	11.433 ms	11.425 ms	11.465 ms	11.450 ms	11.912 ms
bm_tracker_flat	1.661 ms	1.511 ms	1.513 ms	1.714 ms	1.507 ms	1.612 ms	1.510 ms
bm_xapian	1.278 ms	1.364 ms	1.359 ms	1.821 ms	1.994 ms	1.429 ms	3.192 ms
	release=1999/03/31 - 17,251 movies, 3 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	12.485 ms	12.281 ms	12.323 ms	11.981 ms	12.137 ms	11.808 ms	12.552 ms
bm_sqlite	8.247 ms	6.259 ms	6.007 ms	6.300 ms	6.125 ms	5.958 ms	5.921 ms
bm_sqlite_index	0.379 ms	0.297 ms	0.285 ms	0.284 ms	0.252 ms	0.254 ms	0.251 ms
bm_tracker	61.537 ms	60.815 ms	61.014 ms	60.821 ms	61.013 ms	60.850 ms	60.820 ms
bm_tracker_flat	11.063 ms	8.021 ms	8.414 ms	8.690 ms	7.798 ms	7.811 ms	8.313 ms
bm_xapian	5.545 ms	4.561 ms	4.956 ms	4.388 ms	4.321 ms	4.687 ms	4.396 ms
	release=1999/03/31 - 121,587 movies, 12 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	14.005 ms	14.031 ms	12.792 ms	14.354 ms	12.736 ms	13.862 ms	13.374 ms
bm_sqlite	64.517 ms	61.783 ms	61.669 ms	62.418 ms	61.377 ms	61.326 ms	62.036 ms
bm_sqlite_index	9.994 ms	0.403 ms	0.358 ms	0.351 ms	0.368 ms	0.363 ms	3.368 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	62.160 ms	62.760 ms	56.630 ms	60.929 ms	54.310 ms	53.189 ms	58.016 ms
bm_xapian	29.180 ms	28.239 ms	28.080 ms	28.054 ms	27.777 ms	27.615 ms	27.505 ms
	title=The Matrix - 9 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	9.248 ms	8.929 ms	9.139 ms	9.455 ms	9.609 ms	9.128 ms	9.110 ms
bm_sqlite	0.163 ms	0.163 ms	0.163 ms	0.161 ms	0.160 ms	0.163 ms	0.164 ms
bm_sqlite_index	0.167 ms	0.165 ms	0.178 ms	0.164 ms	0.164 ms	0.163 ms	0.165 ms
bm_tracker	0.733 ms	0.484 ms	0.475 ms	0.478 ms	0.481 ms	0.475 ms	0.476 ms
bm_tracker_flat	0.575 ms	0.400 ms	0.380 ms	0.382 ms	0.379 ms	0.387 ms	0.379 ms
bm_xapian	0.226 ms	0.197 ms	0.194 ms	0.191 ms	0.191 ms	0.194 ms	0.190 ms
	title=The Matrix - 1,099 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	10.758 ms	10.578 ms	10.083 ms	10.230 ms	10.555 ms	10.630 ms	10.831 ms
bm_sqlite	0.728 ms	0.524 ms	0.504 ms	0.501 ms	0.506 ms	0.500 ms	0.501 ms
bm_sqlite_index	0.218 ms	0.203 ms	0.201 ms	0.198 ms	0.199 ms	0.277 ms	0.233 ms
bm_tracker	5.906 ms	5.409 ms	5.426 ms	5.453 ms	5.420 ms	5.410 ms	5.344 ms
bm_tracker_flat	1.685 ms	1.471 ms	1.455 ms	1.455 ms	1.440 ms	1.448 ms	1.439 ms
bm_xapian	0.445 ms	0.385 ms	0.398 ms	0.373 ms	0.836 ms	0.451 ms	0.374 ms
	title=The Matrix - 3,216 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	10.138 ms	10.144 ms	10.652 ms	10.124 ms	10.169 ms	10.070 ms	10.547 ms
bm_sqlite	2.587 ms	1.180 ms	1.198 ms	2.202 ms	1.411 ms	1.422 ms	1.288 ms
bm_sqlite_index	0.323 ms	0.300 ms	0.306 ms	0.298 ms	0.493 ms	0.304 ms	0.304 ms
bm_tracker	15.097 ms	14.727 ms	14.692 ms	14.759 ms	14.840 ms	14.888 ms	14.791 ms
bm_tracker_flat	3.727 ms	3.529 ms	3.558 ms	3.545 ms	3.504 ms	3.504 ms	3.520 ms
bm_xapian	0.432 ms	0.353 ms	0.345 ms	0.349 ms	0.348 ms	0.342 ms	0.692 ms
	title=The Matrix - 17,251 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	12.462 ms	11.871 ms	12.020 ms	11.603 ms	12.469 ms	11.850 ms	11.823 ms
bm_sqlite	6.093 ms	6.096 ms	6.130 ms	5.941 ms	5.882 ms	5.959 ms	6.789 ms
bm_sqlite_index	1.431 ms	0.304 ms	0.201 ms	0.200 ms	0.201 ms	0.199 ms	0.199 ms
bm_tracker	79.019 ms	78.831 ms	78.514 ms	78.491 ms	79.423 ms	78.506 ms	78.759 ms
bm_tracker_flat	19.173 ms	20.160 ms	19.373 ms	19.043 ms	18.992 ms	18.961 ms	19.207 ms
bm_xapian	0.422 ms	0.344 ms	0.339 ms	0.335 ms	0.336 ms	0.339 ms	0.345 ms
	title=The Matrix - 121,587 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	13.367 ms	13.395 ms	12.906 ms	13.164 ms	12.856 ms	13.348 ms	12.862 ms
bm_sqlite	62.625 ms	61.341 ms	61.296 ms	61.361 ms	61.248 ms	61.195 ms	61.607 ms
bm_sqlite_index	0.328 ms	0.312 ms	0.300 ms	0.303 ms	0.301 ms	7.473 ms	0.330 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	138.148 ms	131.762 ms	130.937 ms	131.431 ms	131.471 ms	130.975 ms	130.770 ms
bm_xapian	0.833 ms	0.681 ms	0.674 ms	0.687 ms	0.665 ms	0.667 ms	0.665 ms
	director=Quentin Tarantino - 9 movies, 1 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	9.112 ms	9.540 ms	9.671 ms	9.258 ms	9.510 ms	9.597 ms	9.126 ms
bm_sqlite	0.273 ms	0.243 ms	0.243 ms	0.241 ms	0.239 ms	0.239 ms	0.239 ms
bm_sqlite_index	0.282 ms	0.243 ms	0.257 ms	0.244 ms	0.245 ms	0.243 ms	0.337 ms
bm_tracker	0.810 ms	0.547 ms	0.542 ms	0.544 ms	0.541 ms	0.554 ms	0.567 ms
bm_tracker_flat	0.606 ms	0.410 ms	0.398 ms	0.403 ms	0.383 ms	0.459 ms	0.392 ms
bm_xapian	0.215 ms	0.204 ms	0.195 ms	0.197 ms	0.195 ms	0.208 ms	0.194 ms
	director=Quentin Tarantino - 1,099 movies, 9 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	11.574 ms	12.063 ms	11.780 ms	12.169 ms	12.253 ms	11.801 ms	11.939 ms
bm_sqlite	13.775 ms	8.831 ms	9.583 ms	9.506 ms	9.193 ms	9.154 ms	9.452 ms
bm_sqlite_index	13.332 ms	8.963 ms	10.201 ms	9.064 ms	8.925 ms	10.095 ms	8.756 ms
bm_tracker	5.173 ms	4.644 ms	4.546 ms	4.473 ms	4.552 ms	4.472 ms	4.455 ms
bm_tracker_flat	1.137 ms	0.857 ms	0.851 ms	0.855 ms	0.844 ms	0.842 ms	0.844 ms
bm_xapian	0.898 ms	0.878 ms	0.893 ms	0.873 ms	1.000 ms	0.882 ms	0.843 ms
	director=Quentin Tarantino - 3,216 movies, 10 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	12.343 ms	12.175 ms	12.307 ms	12.004 ms	12.235 ms	12.947 ms	12.194 ms
bm_sqlite	40.967 ms	37.867 ms	38.607 ms	37.618 ms	37.487 ms	37.124 ms	38.147 ms
bm_sqlite_index	43.470 ms	36.820 ms	37.027 ms	36.779 ms	36.957 ms	36.585 ms	36.782 ms
bm_tracker	13.707 ms	13.074 ms	12.763 ms	12.740 ms	12.848 ms	12.779 ms	12.855 ms
bm_tracker_flat	2.015 ms	1.559 ms	1.531 ms	1.525 ms	1.530 ms	1.545 ms	1.511 ms
bm_xapian	0.933 ms	0.886 ms	0.908 ms	2.944 ms	1.023 ms	1.030 ms	0.799 ms
	director=Quentin Tarantino - 17,251 movies, 13 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	13.704 ms	14.413 ms	14.331 ms	15.096 ms	14.026 ms	14.492 ms	14.205 ms
bm_sqlite	307.961 ms	308.146 ms	308.565 ms	307.942 ms	308.342 ms	308.387 ms	308.991 ms
bm_sqlite_index	308.011 ms	305.433 ms	305.347 ms	304.567 ms	304.920 ms	305.567 ms	304.404 ms
bm_tracker	72.690 ms	72.075 ms	72.005 ms	71.999 ms	71.938 ms	71.946 ms	72.108 ms
bm_tracker_flat	7.489 ms	6.996 ms	6.877 ms	6.987 ms	7.148 ms	7.088 ms	7.021 ms
bm_xapian	1.087 ms	0.963 ms	1.010 ms	1.151 ms	1.088 ms	0.965 ms	0.959 ms
	director=Quentin Tarantino - 121,587 movies, 14 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	13.546 ms	13.955 ms	13.981 ms	13.854 ms	13.740 ms	14.114 ms	15.816 ms
bm_sqlite	4,752.853 ms	2,793.690 ms	2,800.197 ms	2,795.611 ms	2,800.578 ms	2,794.765 ms	2,801.000 ms
bm_sqlite_index	2,806.890 ms	2,789.648 ms	2,788.729 ms	2,791.168 ms	2,788.102 ms	2,790.845 ms	2,789.475 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	47.801 ms	46.303 ms	46.701 ms	46.640 ms	46.467 ms	46.862 ms	46.448 ms
bm_xapian	20.098 ms	1.260 ms	1.176 ms	1.162 ms	1.156 ms	1.149 ms	1.148 ms
	T* - 9 movies, 9 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	17.303 ms	17.072 ms	16.927 ms	16.539 ms	16.816 ms	16.758 ms	16.797 ms
bm_sqlite	0.547 ms	0.544 ms	0.547 ms	0.541 ms	0.541 ms	0.546 ms	0.544 ms
bm_sqlite_index	0.553 ms	0.549 ms	0.554 ms	0.553 ms	0.658 ms	0.547 ms	0.544 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	2.525 ms	2.302 ms	2.423 ms	2.415 ms	2.372 ms	2.356 ms	2.305 ms
bm_xapian	3.086 ms	2.871 ms	2.947 ms	2.893 ms	3.104 ms	3.022 ms	3.126 ms
	T* - 1,099 movies, 1,098 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	358.775 ms	355.830 ms	350.287 ms	349.816 ms	347.998 ms	356.585 ms	347.143 ms
bm_sqlite	64.679 ms	142.927 ms	143.776 ms	142.847 ms	145.319 ms	147.244 ms	135.600 ms
bm_sqlite_index	62.383 ms	151.941 ms	144.456 ms	144.108 ms	141.330 ms	173.728 ms	169.799 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	199.108 ms	213.355 ms	202.793 ms	196.659 ms	194.937 ms	194.708 ms	195.267 ms
bm_xapian	419.323 ms	516.929 ms	677.357 ms	591.280 ms	599.091 ms	643.124 ms	497.649 ms
	T* - 3,216 movies, 3,204 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	842.413 ms	968.828 ms	958.367 ms	1,002.383 ms	932.222 ms	946.388 ms	1,004.821 ms
bm_sqlite	327.669 ms	415.921 ms	440.198 ms	408.543 ms	432.575 ms	537.572 ms	412.061 ms
bm_sqlite_index	310.218 ms	432.201 ms	413.221 ms	404.165 ms	479.691 ms	431.758 ms	436.533 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	727.867 ms	711.970 ms	722.046 ms	717.685 ms	719.927 ms	713.077 ms	713.843 ms
bm_xapian	1,442.238 ms	1,470.821 ms	1,415.183 ms	1,392.164 ms	1,437.493 ms	1,464.149 ms	1,520.747 ms
	T* - 17,251 movies, ≥ 10,000 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	3,006.139 ms	3,127.174 ms	3,136.617 ms	3,151.197 ms	3,131.469 ms	3,141.155 ms	3,056.497 ms
bm_sqlite	1,481.321 ms	1,388.573 ms	1,468.062 ms	1,533.263 ms	1,422.012 ms	1,442.638 ms	1,456.166 ms
bm_sqlite_index	1,346.717 ms	1,451.410 ms	1,508.228 ms	1,411.643 ms	1,460.563 ms	1,514.390 ms	1,391.342 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	2,945.536 ms	2,938.230 ms	2,957.149 ms	2,959.569 ms	2,972.291 ms	2,933.668 ms	2,936.655 ms
bm_xapian	3,391.825 ms	3,490.307 ms	3,474.203 ms	3,483.310 ms	3,560.886 ms	3,505.060 ms	3,398.937 ms
	T* - 121,587 movies, ≥ 10,000 matches
	t1	t2	t3	t4	t5	t6	t7
bm_lucene++	3,627.408 ms	3,625.588 ms	3,546.610 ms	3,508.233 ms	3,599.160 ms	4,597.857 ms	4,101.686 ms
bm_sqlite	2,182.548 ms	2,109.730 ms	2,109.812 ms	2,121.573 ms	2,104.320 ms	2,117.912 ms	2,145.342 ms
bm_sqlite_index	2,108.863 ms	2,103.648 ms	2,131.009 ms	2,132.823 ms	2,109.655 ms	2,137.286 ms	2,106.779 ms
bm_tracker	-	-	-	-	-	-	-
bm_tracker_flat	8,757.130 ms	9,316.640 ms	8,708.298 ms	8,781.584 ms	8,788.042 ms	8,699.770 ms	8,721.099 ms
bm_xapian	4,805.474 ms	4,528.004 ms	4,692.763 ms	4,640.065 ms	4,618.215 ms	4,647.170 ms	4,674.588 ms