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
--
Posted via http://www.ruby-forum.com/.
Which one is faster?
Measure it. There is Benchmark.
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
SMARTNESS = {
"A" => "you are smart",
"B" => "you are dumb",
}
puts SMARTNESS[grade]
Cheers
robert
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan <lists@ruby-forum.com> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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.
--
Posted via http://www.ruby-forum.com/.
It looks like you're made for each other. 
--
Posted via http://www.ruby-forum.com/.
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 ...
Attachments:
http://www.ruby-forum.com/attachment/7683/benchi.png
--
Posted via http://www.ruby-forum.com/.
What is with Ruby being slow?
On Thu, Aug 16, 2012 at 9:25 PM, Jan E. <lists@ruby-forum.com> wrote:
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.--
Posted via http://www.ruby-forum.com/\.
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
On Thu, Aug 16, 2012 at 9:25 AM, Jan E. <lists@ruby-forum.com> wrote:
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.--
Posted via http://www.ruby-forum.com/\.
--
Jonan Scheffler
@1337807 <http://twitter.com/1337807>
jonanscheffler@gmail.com
(503) 985-6626
Robert Klemme wrote in post #1072532:
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
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan <lists@ruby-forum.com> > wrote:
--
Posted via http://www.ruby-forum.com/\.
Hey, don't uncover our little secret! Darn...
robert
On Thu, Aug 16, 2012 at 4:46 PM, Jan E. <lists@ruby-forum.com> wrote:
It looks like you're made for each other.
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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 Fri, Aug 17, 2012 at 12:03 AM, Regis d'Aubarede <lists@ruby-forum.com>wrote:
Hello,
test done with :
a="x"
if a=="b" then 2
elsif a=="c" then 1
elsif a=="c" then 1
.... 50 elsifa="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 when10 microsecondes with if,
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--
Posted via http://www.ruby-forum.com/\.
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 08/16/2012 09:03 AM, Regis d'Aubarede wrote:
Hello,
test done with :
a="x"
if a=="b" then 2
elsif a=="c" then 1
.... 50 elsifa="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 when10 microsecondes with if,
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
--
Charles Hixson
Nathan Ahmed 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?".
--
Posted via http://www.ruby-forum.com/\.
Robert Klemme wrote in post #1072532:
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
On Thu, Aug 16, 2012 at 4:23 PM, ajay paswan <lists@ruby-forum.com> wrote:
On Thu, Aug 16, 2012 at 1:43 PM, ajay paswan <lists@ruby-forum.com> >> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
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 Rex
2012/8/17 Nathan Ahmed <elihu5991@gmail.com>:
Nathan Ahmed 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.
--
Posted via http://www.ruby-forum.com/\.
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
On Fri, Aug 17, 2012 at 6:24 AM, Nathan Ahmed <elihu5991@gmail.com> wrote:
So then what is the point of ruby if it's just for
human-readability? Isn't it all about functionality?
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 Sun, Aug 19, 2012 at 8:53 AM, Charles Hixson <charleshixsn@earthlink.net> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
and thus also easier to debug.
The point is getting things done.
Am 17.08.2012 12:33, schrieb Bartosz Dziewoński:
2012/8/17 Nathan Ahmed <elihu5991@gmail.com>:
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 Fri, Aug 17, 2012 at 3:33 AM, Bartosz Dziewoński <matma.rex@gmail.com> wrote:
2012/8/17 Nathan Ahmed <elihu5991@gmail.com>:
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.
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
On Mon, Aug 20, 2012 at 6:57 AM, Charles Hixson <charleshixsn@earthlink.net> wrote:
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
