: I have seen this issue come up several times (perhaps the following is
: an oversimplification):
: Someone will suggest a performance enhancement and perhaps supply the
: code. Then there will be a general discussion about the merits of the
: change and the validity of the results, with question
ibles. And the minimum
hardware requirement is a Win98 laptop, which many of our user's have.)
-Original Message-
From: DM Smith [mailto:[EMAIL PROTECTED]
Sent: Friday, December 09, 2005 7:07 AM
To: java-dev@lucene.apache.org
Subject: Re: NioFile cache performance
John Haxby wro
y, December 09, 2005 4:24 AM
To: java-dev@lucene.apache.org
Subject: Re: NioFile cache performance
Robert Engels wrote:
> Using a 4mb file (so I could be "guarantee" the disk data would be in
> the OS cache as well), the test shows the following results.
Which OS? If it
, 2005 7:07 AM
To: java-dev@lucene.apache.org
Subject: Re: NioFile cache performance
John Haxby wrote:
> Robert Engels wrote:
>
>> Using a 4mb file (so I could be "guarantee" the disk data would be in
>> the OS cache as well), the test shows the following results.
>
John Haxby wrote:
Robert Engels wrote:
Using a 4mb file (so I could be "guarantee" the disk data would be in
the OS cache as well), the test shows the following results.
Which OS? If it's Linux, what kernel version and distro? What
hardware (disk type, controller etc).
It's important
Robert Engels wrote:
Using a 4mb file (so I could be "guarantee" the disk data would be in
the OS cache as well), the test shows the following results.
Which OS? If it's Linux, what kernel version and distro? What
hardware (disk type, controller etc).
It's important to know: I/O (and ca
switches into the
OS will be avoided.
-Original Message-From: Paul Smith
[mailto:[EMAIL PROTECTED]Sent: Thursday, December 08, 2005 1:54
PMTo: java-dev@lucene.apache.orgSubject: Re: NioFile
cache performance
Most of the CPU
time is actually used during the
Most of the CPU time is actually used during the synchronization with multiple threads. I hacked together a version of MemoryLRUCache that used a ConcurrentHashMap from JDK 1.5, and it was another 50% faster ! At a minimum, if the ReadWriteLock class was modified to use the 1.5 facilities some si
As a follow-up...
The real performance benefit comes in a shared server environment, where the
Lucene process runs along side other processes - i.e. competes for the use
of the OS file cache. Since the Lucene process can be configured with a
dedicated memory pool, using facilities like NioFile all
