[#14922] alias $gvar — Koji Arai <JCA02266@...>

新井です。

19 messages 2001/10/14

[#15006] Re: eval.c (rb_stack_check): prohibit recursive raising error — WATANABE Hirofumi <eban@...>

わたなべです。

13 messages 2001/10/26
[#15008] Re: eval.c (rb_stack_check): prohibit recursive raising error — Shugo Maeda <shugo@...> 2001/10/26

前田です。

[ruby-dev:14851] Re: Generator

From: Shugo Maeda <shugo@...>
Date: 2001-10-03 03:38:11 UTC
List: ruby-dev #14851
前田です。

At Thu, 27 Sep 2001 20:28:01 +0900,
TAKAHASHI Masayoshi <maki@inac.co.jp> wrote:
> このgenerator、面白いですねー。

面白いですね。

ただ、Rubyのcall/ccは重いので効率がちょっと問題になりますよね。

shugo@studly:~/ruby> time ruby -e '(1..100).each do |i| i end' 
ruby -r generator.rb -e '(1..100).each do |i| i end'  0.03s user 0.00s system 152% cpu 0.020 total
sshugo@studly:~/ruby> time ruby -r generator.rb -e 's = SyncEnumerator.new(1..1000); s.each do |i| i end'                                                       
ruby -r generator.rb -e 's = SyncEnumerator.new(1..1000); s.each do |i| i end  16.54s user 2.20s system 84% cpu 22.157 total

もっとも、これはRubyがVM化されてcall/ccの実装が変われば、改善され
ると思いますが…。
# 木山君のVMはcall/ccやthreadも実装されてるんでしょうか。

あんまり関係ないんですけど、ネットワークがらみのプログラム(ネット
ワークじゃなくても何でも同じだと思いますが)で以下のように細かい粒
度でtimeout.rbを使ったら、効率が随分低下しました。

    def get_line
      line = nil
      timeout(@timeout) do
	line = @socket.gets
      end
      ...
    end

これはスレッドプールを使ったら多少改善されるのかな?

> 少し触ってみました。で、GeneratorではなくSynchronizer改め
> SyncEnumeratorの方ですが、
> 
>  * SyncEnumerator#eachの途中の段階で、あるイレテータの返す値が
>    nilだったとき、イテレートが終わったのか、本当に値がnilだった
>    のかの区別する手段がない
> 
> という点が気になりました。
> でも、どう対応するのがいいんでしょうね? デフォルトを設定できる
> ようにするとか、n番目のイテレータが終了したかを調べるメソッドを
> 作るとかでしょうか(どちらも今一つしっくりこないかも)。

どれかのカーソルに対応する要素がなくなった時点で例外を起こすよう
なオプションもあると便利かもしれないですね。

-- 
前田 修吾
この話がC MAGAZINEの9月号(*1)に間に合ってたらもっと面白くできたのに。
(*1: http://www.shugo.net/article/cmagazine/5th/)

In This Thread