Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: Question about Pattern.matcher performance differences between Java6 and Java7/8 Date: Thu, 26 Dec 2013 13:51:53 +0100 Lines: 34 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: individual.net ElEpnBWJKjfNeul1YfBXGwUpgvRBjTGg5z7scOlHnBos7TPn8= Cancel-Lock: sha1:cpOwKScZ0ri3sEwG1evuRt0bhns= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: Xref: csiph.com comp.lang.java.programmer:27086 On 26.12.2013 02:24, Stefan Ram wrote: > Kevin McMurtrie writes: >> Neither can determine real GC load. What ends up happening is that yo= u >> pull a chunk of suspect code out of your app and run it by itself in a= >> controlled environment to benchmark it. The alternative is using a > > Sometimes, one wants to compare two versions of suspect code, > one of which has some new =BBoptimization=AB, to see whether that > optimization helps indeed as much as hoped for. > > When one needs to optimize, the application must be observably > slow. That means: macroscopically slow, so slow that one can > measure it using a stop watch or at least detect he slowness > somehow. > > In this case, one can compare the two versions in-place. That is: > run the app with the old version and then with the new version. > This will include =BBreal GC load=AB and all. I'm not sure I agree to the "real GC load": if you artificially slow the = application down to a level where you can use a stop watch you have=20 already changed behavior dramatically and all bets are off. Or did you mean it the other way round: you can only apply the stop=20 watch approach if the application is so slow? Kind regards robert