Excerpts from Roshan James's mail of 10 Mar 2005 (EST):
Generators - I did not know about them. I had a look at this -
http://www.ruby-doc.org/stdlib/libdoc/generator/rdoc/classes/Generator.html
It does not look like this is a good think to do at all, because all the
state-management that itertors do for free is lost at the cost of
creating another continuation around it.
I'm not sure what you mean by that, but:
Admittedly this solves the syntactic problem that I was looking for a
solution to, but at a very large cost to the runtime.
There's a definite cost to using generators. Of course, you've already
incurred a huge performance penalty by using Ruby in the first place. Is
the further cost of generators really too much?
I see about a factor of ten slow-down in the following toy example.
It'd be interesting to do more datapoints and see if this is a linear
relationship or what.
ruby -rgenerator -rbenchmark -e 'a=(1..100000).map{|x|x};g=Generator.new(a);[
lambda { a.each { |x| x } },
lambda { while g.next?; g.next; end },
].each {|pr| puts Benchmark.measure(&pr) }'
0.030000 0.000000 0.030000 ( 0.027388)
10.380000 1.190000 11.570000 ( 11.612888)
I found a terse description of zip() at
http://whytheluckystiff.net/articles/rubyOneEightOh.html
Is there a better place I can read up about this? I want to know how
this works.
Unfortunately not, other than the Ruby source code itself.
In my post, I chose the array.each only as an example. Its not arrays
for which I want to do this with - I want to solve the problem for
iterator calls. If zip() internally creates a list of values from both
iterations, then it does not help me. I want to be able to do the actual
computation of the iterator calls in lock-step.
Enum#zip internally turns everything into arrays.
Unless you can deal with the original objects as external (i.e.
Python-style) iterators, this is the price you pay for the niceness of
interal iterators.
···
--
William <wmorgan-ruby-talk@masanjin.net>