mikeash.com pyblog/performance-comparisons-of-common-operations-leopard-edition.html commentshttp://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsmikeash.com Recent CommentsFri, 29 Mar 2024 10:57:57 GMTPyRSS2Gen-1.0.0http://blogs.law.harvard.edu/tech/rssdmpk2k - 2010-04-25 18:52:25http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsWhoops, clicked "post" too soon. <br /> <br />It'd be interesting to see what differences there are between GCC and Clang too.84b9c016b04db784396e0a3a649b4e5cSun, 25 Apr 2010 18:52:25 GMTdmpk2k - 2010-04-25 18:51:25http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsMay I suggest a new benchmark on Snow Leopard? :)dacc0306be00bda24408f4c89cc185c1Sun, 25 Apr 2010 18:51:25 GMTDolphin - 2009-06-12 10:27:30http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsI recently came across this page while trying to learn Obj-C and these metrics and your explanation of how messages are sent was very helpful. After seeing the original test, I thought the cached IMP test seemed similar to a C++ Pointer to member function. I tried adding an additional test using it and it turned out slightly faster than a virtual function call. I tried a similar test using visual studio and the ptmf was about 60% SLOWER than the virtual function call (which lead me to lots of interesting reading on the topic and different implementations). Since gcc seems to have one of the more sane implementations it might be interesting to include if you choose to do any similar tests like this in the future: <br /> <br /><div class="blogcommentquote"><div class="blogcommentquoteinner"> <br />&nbsp;&nbsp;&nbsp;&nbsp;class StubClass *obj = new StubClass; <br />&nbsp;&nbsp;&nbsp;&nbsp; <br />&nbsp;&nbsp;&nbsp;&nbsp;void (StubClass::*func)()=&amp;StubClass::stub; <br />&nbsp;&nbsp;&nbsp;&nbsp;BEGIN( 1000000000 ) <br />&nbsp;&nbsp;&nbsp;&nbsp;(obj-&gt;*func)(); <br />&nbsp;&nbsp;&nbsp;&nbsp;END() <br /></div></div>4483a35097a2db6286fcc920b608e0a9Fri, 12 Jun 2009 10:27:30 GMTmikeash - 2008-02-01 08:55:41http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsI only passed flags needed to compile, so things like -framework Cocoa. It was compiled with no optimization.1401c2a3b0f122eaeaccb18349da6cb1Fri, 01 Feb 2008 08:55:41 GMTjd - 2008-02-01 07:48:04http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsWhich flags did you pass to the compiler?, Eg, -Os, -O3, etc. <br /> <br />79db222c32717f59e72b4e5eaeb1c58eFri, 01 Feb 2008 07:48:04 GMTsmfr - 2008-01-23 13:12:41http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsCan you make a chart that has Tiger and Leopard numbers with a delta? That would make the differences more clear.f7cc7c8ca295df34156247cdee3d05b2Wed, 23 Jan 2008 13:12:41 GMTJordy/Jediknil - 2008-01-15 13:29:35http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsGarbage collection? <br /> <br />Even if you had GC off for the test, the 10.5 frameworks might still generate a few little stubs that eat up that bit of extra time. It's just a guess but it would explain why things got <i>slower</i>. Still doesn't explain the 32/64 question but Voolek made a good point about optimization.1d3be1fd11ec7dfb8e8bd66f12ab8081Tue, 15 Jan 2008 13:29:35 GMTVoolek Varsakharian Pashmaki - 2008-01-14 12:07:26http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner"> <br />I have even less of an idea why it would only be slower on Leopard 32-bit but not 64-bit <br /></div></div> <br /> <br />It is possible that the 32-bit and 64-bit compilers have their own fork of optimizer, memory management stuff, etc. and the 64-bit compiler is optimized heavily while the 32-bit one is not...5ab94607f927e1498143a5c549967621Mon, 14 Jan 2008 12:07:26 GMTmikeash - 2008-01-13 11:33:44http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsI'll be happy to run a new test locking the memory to 3GB if it's not too involved and you can give me more specific instructions. However it will probably have to wait a week or so until after Macworld.f43b1ab0e50fa8cdd77bf234c87e3656Sun, 13 Jan 2008 11:33:44 GMTChris - 2008-01-13 10:39:56http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#comments<div class="blogcommentquote"><div class="blogcommentquoteinner">There is one change to the hardware, in that the computer now has 7GB of RAM instead of 3GB. I do not expect this to influence much.</div></div> <br /> <br />I do not share your sanguineness, I'm afraid. This could easily skew results. The kernel <i>used to</i> allocate certain caches as a percentage of available RAM; I don't know if it still does that, but there is still kernel overhead in managing the extra RAM. Can you rerun these results using the kernel "maxmem" (or whatever it is) boot param to temporarily lock the usable memory to 3GB? <br />066dfe5d5c4f9adaf350e4603c044dc7Sun, 13 Jan 2008 10:39:56 GMTmikeash - 2008-01-13 06:31:24http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsThanks for pointing that out. It's actually an issue with my RSS feed not knowing how to rewrite relative links in the post. I have fixed this by the simple expedient of removing the link from the first paragraph.9eb59974917357dd58e1f5c579ec2ed8Sun, 13 Jan 2008 06:31:24 GMTAhruman - 2008-01-13 05:59:09http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsWoo, my demands are popular! Perhaps they’re marketable? <br /> <br />The link in the first paragraph is broken in the RSS feed. Probably this is some not-very-interesting issue in your software regarding URLs with queries in them.e2749bdbcad037bcac29a9ed65089881Sun, 13 Jan 2008 05:59:09 GMTmikeash - 2008-01-13 05:36:14http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsThat's a good point. The original numbers were done with 32-bit code. I've updated the post to show 64-bit numbers as well.a4aeaa23a942375eccf0e7ef7c4c99aeSun, 13 Jan 2008 05:36:14 GMTleeg - 2008-01-13 05:22:24http://www.mikeash.com/?page=pyblog/performance-comparisons-of-common-operations-leopard-edition.html#commentsJust out of interest, which of Leopard's Objective-C runtimes were you using? I expect the 64-bit one would be faster (but still would hold off optimising for it until I actually had a speed problem)bb680c474ab9dd7265be7da9efa02a88Sun, 13 Jan 2008 05:22:24 GMT