Hi Emmanuel, I've done some changes to your recent new test about Search performance, I first introduced a common "start signal" to all threads to ensure I was testing the concurrency, but wen I did and after you fixed the latest bug (HSEARCH-204) it appeared that Search was performing approximately twice as fast as raw Lucene, quite a suspect behaviour ;-) So I found that the Lucene test was iterating on results from 0 to <=100, not 0 to <100, so actually fetching more than 100 results (101). As Lucene collects the data in it's Hits at batches of 100 elements, this introduced a x2 overhead for the pure Lucene tests. (we could exploit this for .setMaxResults() ) Besides that I introduced some other minor changes: A)Synchronization to read the timings (it doesn't interfere wit timings). B)Use of an Executor C)A start signal (a simple CountDownLatch) D)I had to disable in-thread logging and enable multiple iterations per-thread as it completed too fast to provide a reliable reading of numbers; It's still quite variable (gc?), but gives an idea to compare Lucene to Search. approval to commit? Sanne