From: Tony Arcieri Date: 2012-06-21T02:01:07+09:00 Subject: Re: Benchmark obsession? --0015174c41ca34348a04c2ea58b2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jun 20, 2012 at 7:43 AM, Jan E. wrote: > After having read this list for a while, I wonder why some of you put so > much weight on speed optimizations. I'm not talking about big things > that really make sense but small stuff like "Don't use symbols, they > can't be garbage collected", "Don't concatenate strings, use string > interpolation instead", "Don't use Enumerable#inject to build up > objects" etc. etc. > See http://twitter.com/roflscaletips In my opinion, this is like trying to get a classic car faster. It just > makes no sense. Ruby isn't about speed, it's about elegance and clarity. > If you're looking for speed, you've got the wrong language. Use C or > whatever. There are some very egregious things that libraries can do which they shouldn't and will significantly affect the performance of all running code, like altering the class hierarchy at runtime and thus invalidating all method caches at all call sites. This is bad and people should call that thing out ("DCI" people, I'm looking at you...) However, when it comes to microoptimizing your Ruby code like that, you should probably be using something like perftools to measure. Code has different performance characteristics in different scenarios, so unless you have some real-world code you're trying to make faster, it's kind of a pointless exercise. If you do have said code, you should optimize it in a data-driven way. The best speedups you get will probably be from using code with better algorithmic properties and not from microoptimizing minutiae. -- Tony Arcieri --0015174c41ca34348a04c2ea58b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Jun 20, 2012 at 7:43 AM, Jan E. <lis= ts@ruby-forum.com> wrote:
After having read this list for a while, I wonder why some of you put so much weight on speed optimizations. I'm not talking about big things that really make sense but small stuff like "Don't use symbols, th= ey
can't be garbage collected", "Don't concatenate strings, = use string
interpolation instead", "Don't use Enumerable#inject to build= up
objects" etc. etc.

See http://twitter.com/roflscaletips

In my opinion, this is like trying to get a classic car faster. It just
makes no sense. Ruby isn't about speed, it's about elegance and cla= rity.
If you're looking for speed, you've got the wrong language. Use C o= r
whatever.

There are some very egregious thi= ngs that libraries can do which they shouldn't and will significantly a= ffect the performance of all running code, like altering the class hierarch= y at runtime and thus invalidating all method caches at all call sites. Thi= s is bad and people should call that thing out ("DCI" people, I&#= 39;m looking at you...)

However, when it comes to microoptimizing your Ruby cod= e like that, you should probably be using something like perftools to measu= re. Code has different performance characteristics in different scenarios, = so unless you have some real-world code you're trying to make faster, i= t's kind of a pointless exercise. If you do have said code, you should = optimize it in a data-driven way. The best speedups you get will probably b= e from using code with better algorithmic properties and not from microopti= mizing=A0minutiae.

--
Tony Arcieri

--0015174c41ca34348a04c2ea58b2--