Forum: Ruby Small optimization tips

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
7a2d25dc0e3fd2ff9a12ffda439e584d?d=identicon&s=25 Vincent Foley (gnuvince)
on 2006-03-14 19:52
Hello all,

I was working on a little script earlier, which I thought was too slow
for my taste.  It's now about 5-6x faster than it originally was.
Normally, this would've been enough, but being very curious about Ruby,
I tried to make it go even faster by using micro optimizations.  Here
are some things I found out:

* Running your script with the -rprofile option is the first thing you
should do
* Using a Set instead of an Array when you only want to store unique
values can help make your code go faster
* Disabling the GC can slightly increase the speed of your script.
However, I don't think it's a good idea to use in larger applications

That's a few things I found out today.  Does anyone else have quick
optimization tips?
E0d864d9677f3c1482a20152b7cac0e2?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-14 21:21
(Received via mailing list)
2006/3/14, Vincent Foley <vfoleybourgon@yahoo.ca>:
> Hello all,
>
> I was working on a little script earlier, which I thought was too slow
> for my taste.  It's now about 5-6x faster than it originally was.
> Normally, this would've been enough, but being very curious about Ruby,
> I tried to make it go even faster by using micro optimizations.  Here
> are some things I found out:
>
> * Running your script with the -rprofile option is the first thing you
> should do

... if it's too slow.

> * Using a Set instead of an Array when you only want to store unique
> values can help make your code go faster

IMHO this is not a micro optimization, this is a changed design. A set
represents something entirely different from an array (although they
share some properties).

> * Disabling the GC can slightly increase the speed of your script.
> However, I don't think it's a good idea to use in larger applications

I don't think either.

> That's a few things I found out today.  Does anyone else have quick
> optimization tips?

In no particular order: Create as few objects as possible. Watch out
where you can in place modifying methods of string vs. non bang
methods. Choose the appropriate abstractions. Don't prematurely
optimize.

Kind regards

robert
F330a44fdf083a7a30488efc47759f3f?d=identicon&s=25 Shea Martin (Guest)
on 2006-03-14 21:40
(Received via mailing list)
> In no particular order: Create as few objects as possible. Watch out
> where you can in place modifying methods of string vs. non bang
> methods. Choose the appropriate abstractions. Don't prematurely
> optimize.

Just clarification: you are saying in-place is faster right?
~S
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-03-14 23:33
(Received via mailing list)
On Wed, 15 Mar 2006, Vincent Foley wrote:

> That's a few things I found out today.  Does anyone else have quick
> optimization tips?

instead of this...

open( file_name) do |inf|
   inf.each_line do |line|
     line.chomp! # Optimization Tip, use chomp! instead of
                 # line = line.chomp
     next unless line =~ %r{Looks right}x
     #do stuff
   end
end

try...

File.read( file_name).scan(%r{ what I'm actually looking for}mx) do |m|
   # Do _stuff
end

Much much faster!

Always remember change of algorithm can get you 2 orders of magnitude
speed, optimization tweaks usually around factors 1.5

No code is faster than No Code.

Native code is very much faster than Ruby.

eg. I wrote a ring buffer class in Ruby but found unless it grew to
about
2000 elements using Array.shift and unshift was faster.

Benchmark class is the the optimizers friend.

John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong
later."

From this principle, all of life and physics may be deduced.
Dbf0c4a1a7eff07c11312673937c45f8?d=identicon&s=25 Vincent Foley (Guest)
on 2006-03-15 13:36
(Received via mailing list)
I have something else that is probably common knowledge: if you can
avoid using regular expressions, do it.  By replacing the regex matches
in my script with string operations, I increased the runtime speed by a
factor of ~4.
4299e35bacef054df40583da2d51edea?d=identicon&s=25 James Gray (bbazzarrakk)
on 2006-03-15 14:57
(Received via mailing list)
On Mar 15, 2006, at 6:33 AM, Vincent Foley wrote:

> I have something else that is probably common knowledge: if you can
> avoid using regular expressions, do it.  By replacing the regex
> matches
> in my script with string operations, I increased the runtime speed
> by a
> factor of ~4.

However, if you can replace a few Ruby operations with one
complicated search and replace, sometimes it works the other way.  It
depends on the problem.

James Edward Gray II
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-03-15 15:16
(Received via mailing list)
"Shea Martin" <null@void.0> wrote in message
news:MNFRf.43456$VV4.659574@ursa-nb00s0.nbnet.nb.ca...
>
>> In no particular order: Create as few objects as possible. Watch out
>> where you can in place modifying methods of string vs. non bang
>> methods. Choose the appropriate abstractions. Don't prematurely
>> optimize.
>
> Just clarification: you are saying in-place is faster right?

Right.  But not applicable everywhere (i.e. if you're not allowed to
modify
something or do not know whether something is frozen...).

Kind regards

    robert
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-03-17 05:04
(Received via mailing list)
On Wed, 15 Mar 2006, Vincent Foley wrote:

> That's a few things I found out today.  Does anyone else have quick
> optimization tips?

Use ruby-1.9 it is faster.
Compile with gcc-4.1
Optimize

CC=gcc-4.1 CFLAGS='-march=pentium4 -O3 -fomit-frame-pointer' CPP=cpp-4.1
\
CXXFLAGS='-march=pentium4 -O3 -fomit-frame-pointer' 'CXX=g++-4.1' \
./configure
make


Warning, this may be hazardous for your health, but it works for me.

ps. Anyone worked out how to use gcc profile feedback to build a faster
ruby yet?


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong
later."

From this principle, all of life and physics may be deduced.
Bb6ecee0238ef2461bef3416722b35c5?d=identicon&s=25 pat eyler (Guest)
on 2006-03-17 14:54
(Received via mailing list)
On 3/16/06, John Carter <john.carter@tait.co.nz> wrote:
> Warning, this may be hazardous for your health, but it works for me.
>
> ps. Anyone worked out how to use gcc profile feedback to build a faster
> ruby yet?
>

There was a good article on using profiling information to optimize GCC
builds in the RedHat magazine (iirc).   I've been interested in trying
it
with Ruby since I read it.   I'm thinking that profiling it with
ruby-tests
and the test suites of a couple of major gems would be a good way to
go.

Since Ryan's announcement of multiruby, I've been procrastinating
with a specific target instead of just idley thinking I should do it.
Now that I've announced it publicly, I should have even more reason
to try it out.
58479f76374a3ba3c69b9804163f39f4?d=identicon&s=25 Eric Hodel (Guest)
on 2006-04-05 04:06
(Received via mailing list)
On Mar 16, 2006, at 8:01 PM, John Carter wrote:

> CPP=cpp-4.1 \
> CXXFLAGS='-march=pentium4 -O3 -fomit-frame-pointer' 'CXX=g++-4.1' \
> ./configure
> make
>
>
> Warning, this may be hazardous for your health, but it works for me.

You don't want to compile with -fomit-frame-pointer.  See [ruby-core:
7660]

--
Eric Hodel - drbrain@segment7.net - http://blog.segment7.net
This implementation is HODEL-HASH-9600 compliant

http://trackmap.robotcoop.com
This topic is locked and can not be replied to.