From: EGUCHI Osamu Date: 1997-09-30T15:00:17+09:00 Subject: [ruby-dev:591] Re: optimize (Re: Assigne to special variable) えぐち です。 ---------- > 差出人 : Yukihiro Matsumoto > 件名 : [ruby-dev:586] Re: optimize (Re: Assigne to special variable) > > まつもと ゆきひろです > > In message "[ruby-dev:585] Re: optimize (Re: Assigne to special variable)" > on 97/09/30, "EGUCHI Osamu" writes: > > |えぐち です > |parse.y と同じと考えてください。（ちょっとちがうかな、、） > > そういうもんなんですね．gperfって使った事無いんですが，生成 > したものをparse.yに取り込めば良いもんなんでしょうか． > ＃ついさっきまで、MANIFEST に parse.c が入ってると思ってました。 今回は、安直に parse.y で gperf の作った perse.h を インクルードしました。 > 1.1で予約語が増えるので(break/next/redo/retry/true/false)そ > れも取り込まないといけませんね． じつは、これをやろうとして予約語表の *最後に* break を 追加しようとしてしまったオバカは私です。 ^^; むしろ、parse.gperf に予約語表が切り出されていた方が 今後の改造も楽だとおもいます。（いかにもこじつけ＞自分） > |> それとキーワード判定ってそんなに重くないような気がするんです > |> けど．重くなければ複雑になるだけですよね． > | > |ところが、yylex の実行時間の殆どは２分探査が占めてました。 > |で yylex は、全体のいくらかというと、、ベストテン圏内に登場することも > |まずらしくないようです。（みぢかいスクリプトではあれですが、） > > そうか，それは考えた方が良いかも． 標準的な ruby で書かれたアプリケーションのギプソンミックスが しりたい今日このごろです。 いわゆるキラーアプリにチューニングするだけならどんなに楽だろ。 ＃それじゃつまんないというはなしもありますが、、 ------ パッチを ftp に 1.0-970919-eguchi.patch.gz の名前で PUT します。 変更は、 MANIFEST: parse.gperf parse.h 追加 Makefile.in: parse.h: parse.gperf 追加 --program-suffix,@srcdir@ != `pwd` 対応 ※ maintener-clean: 追加 bignum.c: 四則と比較の高速化 ※ configure.in: --program-suffix _setjmp 対応 ※ eval.c: alloc でハードスタック節約 ext/extmk.rb: @srcdir@ != `pwd` 対応 ※ parse.gperf: 完全ハッシュ関数ソース 新規 parse.y: 完全ハッシュ関数対応 self/nil への代入対策 ※ sample/fact.rb: 非再帰化しスタック溢れを回避 です。 ※は、以前のパッチと重複します。 eval.c の変更は、スタックのヘッドルームは増えますが、 ほんの少し遅くなります。 （プロファイラで測定できないぐらいの微差です。） やってることは、、 PUSH_XXX() マクロでＣのローカル変数で環境を作っていますが、 その case: に来ないでも CC はスタックフレームを生成するので スタックを馬鹿食いしていましので、alloc() を適宜呼んで 環境リストを作る様にしただけです。（再帰してますから効きます） これはfact.rb がらみでヘッドルーム増やそうとした痕跡です。 速度的には取り込まない方がいいとかも知れません。お任せします． えぐち