Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!gegeweb.org!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!tudelft.nl!txtfeed1.tudelft.nl!multikabel.net!newsfeed20.multikabel.net!amsnews11.chello.com!news2.euro.net!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Getter performance Date: Sun, 13 Nov 2011 11:00:33 -0800 (PST) Organization: http://groups.google.com Lines: 132 Message-ID: <4525243.79.1321210833177.JavaMail.geo-discussion-forums@prgt40> References: <4e99f537$0$623$426a74cc@news.free.fr> <4e99fcdf$0$295$14726298@news.sunsite.dk> <4e99fe53$0$281$14726298@news.sunsite.dk> Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 173.164.137.214 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1321210838 28207 127.0.0.1 (13 Nov 2011 19:00:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 13 Nov 2011 19:00:38 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=173.164.137.214; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:9926 BGB wrote: > Eric Sosman wrote: >> Roedy Green wrote: >>> [...] >>> Knuth has frightened people from even investigating speed out of >>> curiosity. >> >> Oh, yeah, right. As in "Ri-i-i-i-ght." +1 Blaming Knuth is about as accurate as saying Jesus caused people to wage wa= r. >> That's why he didn't write three entire volumes of TAOCP (and >> more in the works) in an effort to reach beyond O() notation to the >> constant factors that lie behind. That's why he didn't devote a >> whole lot of text and a whole lot of subtle mathematics to winkling >> out differences between O(n log n) Quicksort and O(n log n) Mergesort >> and O(n log n) Heapsort and O(n log n(?)) Shellsort. That's why he >> never explored threaded trees (they improve some operations by a >> factor of only O(log n) so who cares?). That's why he never bothered >> with Marsaglia's rectangle-wedge-tail method for generating normally- >> distributed random numbers; it's just a trifling micro-optimization. >> >> Oh, sorry, wait: By "frightened" you don't mean "dissuaded," but >> literally "scared." Well, I confess that some of Knuth's math goes Again, Knuth did not cause some low-browed programmer wannabe to feel fear;= that's entirely their own responsibility. >> over my head. But I feel at the same time that someone who shrinks >> from even trying to understand it does not merit the title of >> "engineer." We all feel fear. It's what we do in the face of it that counts. > I tend to distinguish between what would be called "micro optimizations"= =20 > and "macro optimization". >=20 > worrying about the cost of an if/else block, a switch, or performing a=20 > function/method call, is a micro optimization. >=20 > worrying about the choice of an algorithm or program architecture is a=20 > macro-optimization. that is more about what most of the examples were abo= ut. >=20 > generally, macro-optimizations can be reasoned about, and improved upon= =20 > from experience. >=20 > OTOH, most micro-optimizations are worrying about small constant=20 > factors, and tend to make code look nasty if used (and so are better off= =20 > used sparingly). >=20 >=20 > the main issue is that many people, when faced with poor performance (or= =20 > worry about possible poor performance), look right to trying to=20 > micro-optimize whatever they perceive "might be" slow (which tends to be= =20 > bottom-level costs, like the costs of some operation X, ...), rather=20 > than evaluating the larger scale architectural issues ("is there some=20 > way I can avoid this operation altogether?"). >=20 >=20 > but, there can be some overlap: > for example, I recently migrated an interpreter of mine from using a=20 > "loop-and-switch" strategy to using threaded code. >=20 > this could be argued to be a micro-optimization (me afraid of the small= =20 > constant overhead of the switch), but actually it was more motivated by= =20 > flexibility: there are some things which can be done with threaded code= =20 > which can't be so readily done using fixed-form logic within a switch. >=20 > so, debatably, it wasn't even really an optimization in the first place,= =20 > it only had the side-effect of slightly improving performance. >=20 >=20 > OTOH, I recently also made an optimization to my type-checking code=20 > which reduced the cost of a type-lookup operation by feeding the pointer= =20 > through a hash (seeing if the pointer recently had its type looked up). >=20 > however, even though it did effect behavior (it skipped the more=20 > expensive operation of looking up an object in the heap), I still=20 > classify this as a micro-optimization (however, to my defense, the=20 > profiler was showing a lot of time going into type-lookups in this case). >=20 > similarly, it exhibited the usual micro-optimization property in that it= =20 > added some hair to the effected code (some logic to worry about a hash,= =20 > and a few calls added elsewhere to flush the hash). >=20 > more so, it is not likely to be a uniformly distributed optimization: it= =20 > will not improve the performance of type-checking things like fixnums,=20 > which don't involve such a heap lookup in the first place. The problem isn't micro-optimization, as your experience supports. The pro= blem, as Knuth said, is _premature_ optimization. That's optimization when= you don't have enough data to support that what you do actually optimizes = anything. Your "macro-optimization" is optimization for which you have enough evidenc= e early on. Choice of algorithm falls into this category. The scenario you describe of incidental optimization, where a change made f= or algorithmic or modeling reasons improved performance, is not "optimizati= on" in the sense of change intended to produce better performance. Unless = you've done extensive measurement on multiple platforms in varied usage pat= terns, you actually don't have enough data to reliably aver improved perfor= mance, but since that's irrelevant to the change's purpose that's all right= . The scenario where you intentionally changed a detail of the code to improv= e performance, based on profiling and evidence that the work actually had t= he desired effect, may be "micro-optimization", but so what? It's not prem= ature. You actually demonstrated beautifully in your post what is and is not prope= r for optimization. --=20 Lew