Good catch, go ahead for the commit.

What do you mean by we could exploit this for .setMaxResults()? How?

On Jun 2, 2008, at 14:15, Sanne Grinovero wrote:

> 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

_______________________________________________
hibernate-dev mailing list
hibernate-dev@(protected)
https://lists.jboss.org/mailman/listinfo/hibernate-dev