Issue #6183 has been updated by gregolsen (Innokenty Mikhailov).

File lazy_enumerator_hybrid.diff added

(Yusuke Endoh) wrote:

>    (1..10).lazy.select {|x| false }.map {|x| p x }.to_a
>  should print nothing, but it actually prints 1, 2, ..., 10

Fixed, thanks.

>  But I guess implementing
>  other methods, especially, #cycle and #zip, will make some
>  functions (process_element and lazy_iterator_block) complex
>  and hard to maintain.

Agree, those methods (especially #cycle) will be hard to implement in terms of procs chaining approach.

(Nobu Nakada) wrote:
>  So I want to see this being merged in an extensible way.

I came up with a new hybrid patch.
It uses procs chaining to handle lazy #map and #select, and current enumerator chaining approach for other methods.
I believe this is an extensible way. We can move forward step by step and we can stop any time.
If those tricky #zip and #cycle methods optimization won't worth the code complexity added - we can leave it as it is: based on enumerator chaining.
See new lazy_enumerator_hybrid.diff (tests are green except test_inspect).

Please, let me know you thoughts about this.

----------------------------------------
Bug #6183: Enumerator::Lazy performance issue
https://bugs.ruby-lang.org/issues/6183#change-25714

Author: gregolsen (Innokenty Mikhailov)
Status: Assigned
Priority: Low
Assignee: nobu (Nobuyoshi Nakada)
Category: 
Target version: 
ruby -v: ruby 2.0.0dev (2012-03-17 trunk 35075) [x86_64-linux]


I benchmarked Enumerator::Lazy and that's what I got:
                 user     system      total        real
Lazy:        0.690000   0.010000   0.700000 (  0.733160)
Normal:      0.160000   0.010000   0.170000 (  0.186695)

It seems like even with 4 chain links and 3000 elements in initial array, Lazy enumerator is almost 4(!) times slower than the normal case.

Instead of performance benefit we've got 4 times performance drawback.

See test file attached.


-- 
http://bugs.ruby-lang.org/