[hibernate-dev] Re: Search: some changes to new perf tests

[Emmanuel Bernard]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev