[#20083] non-block IO with TCPSocket — dn <daisuke@...>

初投稿の中村と申します。よろしくお願いします。

19 messages 2000/01/06
[#20084] Re: non-block IO with TCPSocket — Tomoyuki Kosimizu <greentea@...2.so-net.ne.jp> 2000/01/06

越水です。

[#20091] Re: non-block IO with TCPSocket — とみたまさひろ <tommy@...> 2000/01/06

とみたです。

[#20133] おききしたーいでーす — akimaru <akimaru@...>

17 messages 2000/01/09
[#20138] Re: おききしたーいでーす — akimaru <akimaru@...> 2000/01/09

[#20237] Ruby/Tk multi interpreter — nagai@...

永井@知能.九工大です.

21 messages 2000/01/17
[#20242] Re: Ruby/Tk multi interpreter — nagai@... 2000/01/17

永井@知能.九工大です.

[#20248] Re: Ruby/Tk multi interpreter — Hideto ISHIBASHI <s34204@...> 2000/01/17

石橋秀仁です。

[#20254] Re: Ruby/Tk multi interpreter — nagai@... 2000/01/18

永井@知能.九工大です.

[#20271] Re: Ruby/Tk multi interpreter — Hideto ISHIBASHI <s34204@...> 2000/01/18

石橋秀仁です。

[#20249] FTP.open err for Windows95 — "Y Kataoka" <kataoka@...>

初めまして、片岡@KLUGと申します。

18 messages 2000/01/17
[#20252] Re: FTP.open err for Windows95 — "NAKAMURA, Hiroshi" <nakahiro@...> 2000/01/18

なひです.

[#20342] How to build ruby(current) with cygwin — KORIYAMA Naohiro <kory@...2.so-net.ne.jp>

はじめまして、こおりやまです。

19 messages 2000/01/23
[#20362] Re: How to build ruby(current) with cygwin — WATANABE Hirofumi <Hirofumi.Watanabe@...> 2000/01/24

わたなべです.

[#20422] Re: How to build ruby(current) with cygwin — Masaki Suketa<CQN02273@...> 2000/01/29

Win32OLE の作者の助田です.

[#20394] ruby-1.4.3 port to HPUX 11.00 — matz@... (Yukihiro Matsumoto)

まつもと ゆきひろです

15 messages 2000/01/26

[ruby-list:20060] Re: RD with method index (again)

From: Minero Aoki <aamine@...>
Date: 2000-01-05 14:51:30 UTC
List: ruby-list #20060
あおきです。

  In mail "[ruby-list:20058] Re: RD with method index (again)"
    Toshiro Kuwabara <toshirok@yb3.so-net.ne.jp> wrote:

> Toshです。

> >> すいません。間違えてました。
> >> おっしゃる通り、WHITELINEはその位置だと許されていません。
> >> これはRDtoolの実装上の問題なのですが、RDの仕様はこういう細かい事まで
> >> 決められてはいませんし、WHITELINEがその位置にいれられても特に便利な
> >> わけでもないですので、まあいいかな、と思ってます。
> >
> >ぼくはその機能すごく欲しいです。
(略)
> う、そうですか。では善処します。
> # 単純に直そうとしたら衝突が10個ほど増えてしまって、泡食って
> # 戻したのですが。(^^;;

よろしくおねがいします。特に急ぎませんので。

ところで衝突の方ですが、原因はメッセージに出てるとおり rule 30 35 40 です。
おそらくトップレベルのリストに対応するためだと思うんですが、
これが入っていることで

* first
* second

のような場合に first,second ふたつの項目をもつリストなのか、
first のなかにネストしたリスト second が入っているのか区別が
できなくなります。
(ただ、衝突するとシフトが優先なので結果としてはうまくいってます。
 安心してていいのかは知らないんですけど…)

真面目に解消するとしたら、enumlist: enumlistitems とかをやめて、
INDENT が必要なところと不要なところをきりわけるのがよいんでないかと
思います。


> >どこで時間を食ってるのかは調べてませんが、
> >これらの修正でちょっとは速くなるんでないかと思います。
> 
> 手元で試してみた簡単なテストではruby-man.rdだとパースにかかってる時間
> が6〜7割って感じでした。
> 
> しかし、さすがにruby-man.rdのような8500行もあるドキュメントだと15秒
> (PentiumMMX200Mhzで)くらいかかってしまいますが、200行程度ならほとんど
> 待ちませんから、RDの文法を考えるとRaccの吐くパーサの性能は結構いいのだ
> ろうと感じてます。
> # 他と比較してないので何とも言えませんが。

試してみました。確かに ruby-man.rd は時間かかりますね。
celeron333A + 128MB で 11秒弱でした。
profile.rb で調べてみると、

  %   cumulative   self              self     total
 time   seconds   seconds    calls  ms/call  ms/call  name
 19.68    84.72     84.72    19016     4.46     6.86  RD::RDParser#next_token
 11.79   135.47     50.75    14774     3.44    21.04  Array#each
  8.50   172.05     36.58   117051     0.31     0.31  Regexp#===
  5.69   196.57     24.52        1 24516.67 36866.67  RD::RDTree#preprocess
  4.76   217.05     20.48     1720    11.91   176.71  Racc::Parser#_c_parse
  3.81   233.45     16.40     1721     9.53   373.27  RD::RDInlineParser#parse
  3.67   249.27     15.82     8698     1.82    23.17  RD::Verbatim#each_element
  3.10   262.63     13.37    45465     0.29     0.29  Hash#[]
  3.04   275.73     13.10     2593     5.05     7.77  RD::RDParser#cut_off
  2.99   288.60     12.87    40567     0.32     0.32  Array#push
(以下略)

という結果になりました。
やはり next_token を中心とするスキャン系統が圧倒的に時間かかってますね。
とりあえず、next_token が遅い原因は文字列埋めこみの正規表現ですね。
これを \s+ と currentIndent == $1 とかに直せば多少速くなるんでは?

あとは、block-parser と inline-parser をひとつにまとめるとか、
ファイルを配列でなく文字列に読みこんで strscan でスキャンするとか…
(荒技だ。)
-------------------------------------------------------------------
あおきみねろう

In This Thread