Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.co.uk;
  h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID;
  b=jjrC4J/1c451U3JAy8or+fWWuB9z9dvZZggbHdC9Kg2o9G/D5FDqbZalPUfkmSWM7dEvsLlqm+OhvxBDJXHIlovUVJu3aX0ZVbFIiLqM6yuYCtGf2LSu/n9/5HRxRUze+Ewftq6Ce91XP5HJPEB5+C5YrZg58l/w4MV6Q4z1opk=;
Date: Mon, 11 Feb 2008 08:32:03 +0000 (GMT)
From: eks dev <eksdev@yahoo.co.uk>
Subject: Re: [jira] Created: (LUCENE-1172) Small speedups to DocumentsWriter
To: java-dev@lucene.apache.org
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Message-ID: <900049.82098.qm@web23015.mail.ird.yahoo.com>

Robert, =0A=0Ayou may or may not be right, I do not know. The only way to p=
rove it would be to show you can do it better, no?=0AIf you are so convince=
d this is wrong, you could, much better than quoting textbooks:=0A =0Aa) wr=
ite better patch, get attention with something you think is "better bottlen=
eck" =0Ab) provide realistic "performance tests" as you dispute the measure=
ment provided here=0A=0AIt has to be that concrete, academic discussions ar=
e cool, but at the end of a day, it is the code that executes that counts.=
=0A=0Acheers, =0Aeks=0A=0A----- Original Message ----=0AFrom: robert engels=
 <rengels@ix.netcom.com>=0ATo: java-dev@lucene.apache.org=0ASent: Sunday, 1=
0 February, 2008 9:15:30 PM=0ASubject: Re: [jira] Created: (LUCENE-1172) Sm=
all speedups to DocumentsWriter=0A=0AI am not sure these numbers matter. I =
think they are skewed because  =0Ayou are probably running too short a test=
, and the index is in memory  =0A(or OS cache).=0A=0AOnce you use a real in=
dex that needs to read/write from the disk, the  =0Apercentage change will =
be negligible.=0A=0AThis is the problem with many of these "performance cha=
nges" - they  =0Ajust aren't real world enough.  Even if they were, I would=
 argue that  =0Acode simplicity/maintainability is worth more than 6 second=
s on a  =0Aoperation that takes 4 minutes to run...=0A=0AThere are many peo=
ple that believe micro benchmarks are next to  =0Aworthless. A good rule of=
 thumb is that if the optimization doesn't  =0Aresult in 2x speedup, it pro=
bably shouldn't be done. In most cases  =0Aany efficiency gains are later l=
ost in maintainability issues.=0A=0ASee http://en.wikipedia.org/wiki/Optimi=
zation_(computer_science)=0A=0AAlmost always there is a better bottleneck s=
omewhere.=0A=0AOn Feb 10, 2008, at 1:37 PM, Michael McCandless wrote:=0A=0A=
>=0A> Yonik Seeley wrote:=0A>=0A>> I wonder how well a single generic quick=
Sort(Object[] arr, int low,=0A>> int high) would perform vs the type-specif=
ic ones?  I guess the main=0A>> overhead would be a cast from Object to the=
 specific class to do the=0A>> compare?  Too bad Java doesn't have true gen=
erics/templates.=0A>=0A>=0A> OK I tested this.=0A>=0A> Starting from the pa=
tch on LUCENE-1172, which has 3 quickSort methods=0A> (one per type), I cre=
ated a single quickSort method on Object[] that=0A> takes a Comparator, and=
 made 3 Comparators instead.=0A>=0A> Mac OS X 10.4 (JVM 1.5):=0A>=0A>     o=
riginal patch --> 247.1=0A>   simplified patch --> 254.9 (3.2% slower)=0A>=
=0A> Windows Server 2003 R64 (JVM 1.6):=0A>=0A>     original patch --> 440.=
6=0A>   simplified patch --> 452.7 (2.7% slower)=0A>=0A> The times are best=
 in 10 runs.  I'm running all tests with these JVM=0A> args:=0A>=0A>   -Xms=
1024M -Xmx1024M -Xbatch -server=0A>=0A> I think this is a big enough differ=
ence in performance that it's=0A> worth keeping 3 separate quickSorts in Do=
cumentsWriter.=0A>=0A> Mike=0A>=0A> ---------------------------------------=
------------------------------=0A> To unsubscribe, e-mail: java-dev-unsubsc=
ribe@lucene.apache.org=0A> For additional commands, e-mail: java-dev-help@l=
ucene.apache.org=0A>=0A=0A=0A----------------------------------------------=
-----------------------=0ATo unsubscribe, e-mail: java-dev-unsubscribe@luce=
ne.apache.org=0AFor additional commands, e-mail: java-dev-help@lucene.apach=
e.org=0A=0A=0A=0A=0A=0A=0A      ___________________________________________=
_______________=0ASent from Yahoo! Mail - a smarter inbox http://uk.mail.ya=
hoo.com=0A


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org