Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!kuling!cia.docs.uu.se!andand From: andand@cia.docs.uu.se (Anders Andersson) Newsgroups: comp.lang.c Subject: Re: low level optimization Message-ID: Date: 15 Apr 91 13:41:06 GMT References: <1991Apr9.213601.12309@agate.berkeley.edu> <1991Apr11.150858.4242@odin.diku.dk> Sender: news@kuling.UUCP Lines: 45 In <1991Apr11.150858.4242@odin.diku.dk> juul@diku.dk (Anders Juul Munch) writes: [ stuff deleted ] > I once read saw an implementation of quicksort in a >magazine, which contained code like: > array[index++] = something; >They stated it was written that way for efficiency. That's crazy. If you want efficiency in QSort you should use pointer arithmetic like: *(pointer++) = something; Then it makes a difference... OK, OK, not true an all machines but *absolutly* true on a MC600x0. (Yes, I've tried it!) >I tried compiling that code, together with the rewrite > array[index] = something; > index++; >And then I looked at the code that my "real-world" compiler >(Turbo C++ 1.0) generated for these two code fragments - > Identical! I can't imagine a compiler where they wouldn't be. (Unless there is some strange addressing modes on the machine). >The morale of the story is, don't use increment/decrement-operators >within other expressions - it makes the code less readable >and it's probably doesn't give you any performance gain anyway. The moral of my comment is, if you want speed you'd better not stop half way - go for pointer arithmetic and make your code truly unreadable. (But run a profiler first... You might not want it everywhere...) [ name and disclamer deleted ] -Anders Andersson (andand@cia.docs.uu.se)