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.
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!
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.
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!
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.
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.
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.
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.
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.
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.
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
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.
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:
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
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:
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!
View Online
Download
DownloadDear 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.
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.
You can just add unanalyzed fields and use term queries on them like kamstrup pointed out.
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 [-263..263-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.
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.
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.
![rating:[90 TO 99]](http://taschenorakel.de/files/fts-benchmark/ftsds1.png)
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.
![release:[1999/01/01 TO 1999/09/30]](http://taschenorakel.de/files/fts-benchmark/ftsds2.png)
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.
| 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 |