Which one is faster?
for example:
if grade==“A”
puts(“you are smart”)
elsif grade==“F”
puts(“you are dumb”)
end
###########################Vs
case grade
when “A”
puts(“you are smart”)
when “B”
puts(“you are smart”)
end
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan [email protected]
wrote:
Which one is faster?
Measure it. There is Benchmark.
puts(“you are smart”)
when “B”
puts(“you are smart”)
end
SMARTNESS = {
“A” => “you are smart”,
“B” => “you are dumb”,
}
puts SMARTNESS[grade]
Cheers
robert
Dude, does it really matter if one variant is some microseconds faster
than the other? Ruby is so slow by itself that this kind of
nanobenchmarking is just insane.
If you want speed, use C (or even assembler). Ruby is the completely
wrong language for this.
Could have been stated a little more politely but he’s right. If you
find
you’re looking to optimize that intensely you probably don’t want an
interpreted language.
I generally try to avoid case statements simply because it makes it easy
for me or another programmer to come along in the future and add another
case, increasing the branching in a bit of code that should probably
have
only done one thing in the first place.
Best of luck
Nathan A. wrote in post #1072547:
What is with Ruby being slow?
Compared to a native program written in a low level language like C,
Ruby is extremely slow.
That’s because it was never meant to be fast. Ruby was written to be
human-friendly, not machine-friendly. So simplicity and conciseness are
more important than saving CPU cycles.
I find it sad that people keep fumbling with senseless benchmarks rather
than make their code clear. Your question should have been “Which one
is easier to read?”, not “Which one is faster?”.
What is with Ruby being slow?
Robert K. wrote in post #1072532:
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan [email protected]
wrote:Which one is faster?
Measure it. There is Benchmark.
means? what measure? and who’ll measure?
puts(“you are smart”)
when “B”
puts(“you are smart”)
endSMARTNESS = {
“A” => “you are smart”,
“B” => “you are dumb”,
}
is it mapping? looks like one.
puts SMARTNESS[grade]Cheers
robert
Whats that
It looks like you’re made for each other. 
On Thu, Aug 16, 2012 at 4:46 PM, Jan E. [email protected] wrote:
It looks like you’re made for each other.
Hey, don’t uncover our little secret! Darn…
robert
Hello,
test done with :
a=“x”
if a==“b” then 2
elsif a==“c” then 1
elsif a==“c” then 1
… 50 elsif
a=“x”
case a
when “g” then 1
when “i” then 1
when “j” then 1
when “k” then 1
when “l” then 1
when “b” then 1
… 50 when
10 microsecondes with if,
231 nanosecondes with case
I use benchi, (from ruiby, see attachment), for this kind of test.
If you need performences, try mirah with a jvm …
So then what is the point of ruby if it’s just for human-readability?
Isn’t
it all about functionality? What good are interpreted languages? Not
saying
they aren’t, yet still.
On Thu, Aug 16, 2012 at 4:23 PM, ajay paswan [email protected]
wrote:
Robert K. wrote in post #1072532:
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan [email protected]
wrote:Which one is faster?
Measure it. There is Benchmark.
means? what measure? and who’ll measure?
You want to know which one is faster so you’ll measure it.
require ‘benchmark’
Benchmark.bm do |b|
…
end
http://www.ruby-doc.org/stdlib-1.9.3/libdoc/benchmark/rdoc/index.html
SMARTNESS = {
“A” => “you are smart”,
“B” => “you are dumb”,
}
is it mapping? looks like one.
It’s a Hash stored in a constant. A hash lookup is typically quite
fast compared to control flow - especially if you increase the number
of alternatives. But: measure it!
puts SMARTNESS[grade]
Cheers
robert
Whats that
What? That’s my name.
Kind regards
robert
Nathan A. wrote in post #1072649:
So then what is the point of ruby if it’s just for human-readability?
What? Don’t you think that there should be different languages for
different purposes?
That’s like saying that sports cars are the only cars that make sense.
Am 17.08.2012 12:33, schrieb Bartosz Dziewoński:
2012/8/17 Nathan A. [email protected]:
So then what is the point of ruby if it’s just for human-readability?
That’s precisely the point. Fast to write, easy to read.
and thus also easier to debug.
The point is getting things done.
On Fri, Aug 17, 2012 at 6:24 AM, Nathan A. [email protected]
wrote:
So then what is the point of ruby if it’s just for
human-readability? Isn’t it all about functionality?
Ruby does indeed have excellent functionality, what with
block-passing, meta-programming, the mix of tools from the OO and
functional paradigms, etc. It just doesn’t have excellent speed of
execution. What the legibility buys us is speed of creation and
maintenance.
Back in the olden days, CPU time was far more expensive than the
amount of programmer time needed to save that much CPU time.
(Generally speaking, that is, and obviously not for programs that had
already gone through thorough optimization.) Nowadays, cheap
computers are so blazing fast, especially when compared to data
transmission over the Internet, that execution speed is rarely a
priority. Now it’s time-to-market, and occasionally time-to-fix or
time-to-upgrade… in other words, programmer time. And that’s where
Ruby shines.
-Dave
2012/8/17 Nathan A. [email protected]:
So then what is the point of ruby if it’s just for human-readability?
That’s precisely the point. Fast to write, easy to read.
Isn’t
it all about functionality? What good are interpreted languages? Not saying
they aren’t, yet still.
Ruby (as well as other scripting languages) have the functionality,
they only don’t have speed. They are good for complicated tasks which
would be tedious to write in lower-level languages, as well as tasks
where you don’t need the speed of lightning, or there already exists a
different, worse bottleneck.
– Matma R.
On Fri, Aug 17, 2012 at 3:33 AM, Bartosz Dziewoński
[email protected] wrote:
2012/8/17 Nathan A. [email protected]:
So then what is the point of ruby if it’s just for human-readability?
That’s precisely the point. Fast to write, easy to read.
And fast-to-write also means that it is quicker to get working code,
which you can benchmark and find where the actual performance
bottlenecks are (which may not be where you’d initially expect), and
refactor those for performance – whether that’s more carefully
crafted Ruby, or using a lower-level language like C or Java.
It lets you spend your programming effort where they are most needed.
On Sun, Aug 19, 2012 at 8:53 AM, Charles H.
[email protected] wrote:
FWIW, I would prefer to be using a faster language, but I also prefer a
language that’s rapid to develop in. And “premature optimization” is a
problem that is endemic to programmers that are concerned about execution
speed.
+2
Quite often what you really need is a better algorithm. (But it
sure is nice to be able to tell is some choice is going to really slow
things down.
But that statement often needs to be taken with a large grain of salt
since often you cannot make a general statement about performance of a
particular piece of code which always applies without the context.
Measuring is the most reliable and fastest way to know.
I will often write special case pattern processors rather than
using regular expressions because of this.
What patterns did you process? Can you give more detail? I am curios
because usually regular expressions are faster.
It may not be true any longer,
but at one point I timed one of my problems, and special case code in ruby
was considerably more than 50 times faster than using a regular expression.
That was years ago, and as I said it may not be true any longer. But I tend
to presume that it’s still true, and the only way to really be sure is to
run exhaustive timing tests after every library or compiler change.
You are comparing apples with oranges here: MRI has changed
dramatically from 1.8 to 1.9 and so did the regexp engine. I may be
the regexp engine internals which make a difference now or a badly
crafted regexp. Without knowing more about your code your statement
is basically meaningless to us.
Kind regards
robert
On 08/16/2012 09:03 AM, Regis d’Aubarede wrote:
a=“x”
231 nanosecondes with caseI use benchi, (from ruiby, see attachment), for this kind of test.
If you need performences, try mirah with a jvm …Attachments:
http://www.ruby-forum.com/attachment/7683/benchi.png
Looks like you’ve found a “case” where case is better than if. Not too
surprising, given that case should be optimized for multi-multi-way
jumps, and if should handle the binary case better.
I disagree with those who say that the timing considerations aren’t
important. They may not rule (if they did you wouldn’t choose Ruby),
but they will always be important. If you can notice the difference
when looping 50 times, it would be rather significant when looping
50_000 times.
That said, Ruby is a lot faster than it used to be. But you are right,
I often wonder which approach would be the more efficient, and very high
level languages tend to hide that from you.
FWIW, I would prefer to be using a faster language, but I also prefer a
language that’s rapid to develop in. And “premature optimization” is a
problem that is endemic to programmers that are concerned about
execution speed. Quite often what you really need is a better
algorithm. (But it sure is nice to be able to tell is some choice is
going to really slow things down. I will often write special case
pattern processors rather than using regular expressions because of
this. It may not be true any longer, but at one point I timed one of my
problems, and special case code in ruby was considerably more than 50
times faster than using a regular expression. That was years ago, and
as I said it may not be true any longer. But I tend to presume that
it’s still true, and the only way to really be sure is to run
exhaustive timing tests after every library or compiler change.
On Mon, Aug 20, 2012 at 6:57 AM, Charles H.
[email protected] wrote:
The point was that because it’s hard to tell what is fast and what is slow,
bad decisions are often made.
The situation is not that bad. For example, we know that - from a
certain number of entries on - it is much faster to use hash lookup
than sequential lookup. Where exactly the point is from which on it’s
faster depends on the specific situation (hit rate, hash functions
etc.). Whether a particular piece of code is a significant
performance hog in a certain program can only be judged by measuring.
But sill it does make sense to use a Hash as general lookup tool which
generally will be quite good decision.
I was using my current habit of avoiding
regular expressions as an example of that.
There you have a bad habit IMHO. Regular expressions are often faster
in Ruby because they are implemented in C and do not need to create as
many objects with GC overhead as any solution implemented in Ruby is
likely to have.
I had heard that the regular
expression parser had been totally re-written, but because it would take a
lot of work to find out the details, I tend to cling to an habit which may
now be bad, even though it was once appropriate.
You do not need to know too many details; you could just try it out
and measure it, don’t you think?
Cheers
robert