Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Cecil Westerhof Newsgroups: comp.lang.java.programmer Subject: Re: A third easy performance optimisation needed Date: Thu, 13 Jul 2017 18:37:00 +0200 Organization: Decebal Computing Lines: 82 Message-ID: <87eftk47kj.fsf@munus.decebal.nl> References: <87d1946ab3.fsf@munus.decebal.nl> <87pod44foe.fsf@munus.decebal.nl> <99effbd1-7b12-4b43-8086-952d3557ae5e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: mx02.eternal-september.org; posting-host="cea988b749795bfe5e66959d383985c6"; logging-data="28359"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/EzuJQxbFPCqE1wBuhXQQ74+KFo0KwxQU=" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) Cancel-Lock: sha1:jrFuP5Drsz7F3PN1YwvyBqIDET8= sha1:3pqZFgEs8VST6pCSK7kf4YH+r+8= X-Homepage: http://www.decebal.nl/ Xref: csiph.com comp.lang.java.programmer:36899 Eric Douglas writes: > On Thursday, July 13, 2017 at 9:44:17 AM UTC-4, Cecil Westerhof wrote: >> >> Look at the example at: >> https://github.com/CecilWesterhof/JavaExamples/blob/master/BoxedTest.java >> >> And it also shows that using a long where an integer is sufficient it >> can have a gigantic difference. On my system the long/integer (which >> already takes a third less time in the first run) is after 5 runs >> about 2½ million times faster as after the first run, while the >> long/long part is not optimised. See my reply in: >> One code is aggressively optimised, while another not. Why? >> > > I could be wrong but it looks to me that your test code here is significantly flawed. It was brought up in that other thread that the test was flawed. > > If you're testing something 5 times you're not getting a real world sample. Depending how long each iteration takes I would run 1,000 if not 1,000,000. OK, I changed the code. I still repeat it five times, but I now have an inner loop that repeats it 100_000_000 times. I still see significant differences: 17:43:40: Timing long int 17:43:40: took 1.57E-02 seconds. 17:43:40: took 1.33E-01 seconds. 17:43:41: took 1.24E-01 seconds. 17:43:41: took 1.24E-01 seconds. 17:43:41: took 1.24E-01 seconds. 17:43:41: Timing long long 17:43:41: took 1.04E+01 seconds. 17:43:51: took 1.05E+01 seconds. 17:44:02: took 1.04E+01 seconds. 17:44:12: took 1.04E+01 seconds. 17:44:23: took 1.04E+01 seconds. 17:44:33: Timing Long int 17:44:33: took 7.31E+01 seconds. 17:45:46: took 7.64E+01 seconds. 17:47:03: took 8.02E+01 seconds. 17:48:23: took 7.38E+01 seconds. 17:49:37: took 8.38E+01 seconds. 17:51:00: Timing Long long 17:51:00: took 8.51E+01 seconds. 17:52:26: took 8.47E+01 seconds. 17:53:50: took 8.41E+01 seconds. 17:55:14: took 8.44E+01 seconds. 17:56:39: took 8.43E+01 seconds. 17:58:03: Timing long Integer 17:58:03: took 3.44E+01 seconds. 17:58:37: took 3.44E+01 seconds. 17:59:12: took 3.44E+01 seconds. 17:59:46: took 3.48E+01 seconds. 18:00:21: took 3.44E+01 seconds. 18:00:55: Timing long Long 18:00:55: took 4.21E+01 seconds. 18:01:38: took 4.26E+01 seconds. 18:02:20: took 4.23E+01 seconds. 18:03:02: took 4.22E+01 seconds. 18:03:45: took 4.25E+01 seconds. 18:04:27: Timing Long Integer 18:04:27: took 9.11E+01 seconds. 18:05:58: took 8.99E+01 seconds. 18:07:28: took 8.99E+01 seconds. 18:08:58: took 9.00E+01 seconds. 18:10:28: took 8.96E+01 seconds. 18:11:58: Timing Long Long 18:11:58: took 9.59E+01 seconds. 18:13:34: took 9.63E+01 seconds. 18:15:10: took 9.55E+01 seconds. 18:16:45: took 9.53E+01 seconds. 18:18:21: took 9.54E+01 seconds. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof