ruby-dev

えぐち です。

----------
> 差出人 : Yukihiro Matsumoto <matz@netlab.co.jp>
> 件名 : [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" <eguchi@shizuokanet.or.jp> 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 がらみでヘッドルーム増やそうとした痕跡です。
速度的には取り込まない方がいいとかも知れません。お任せします．

	えぐち

Thread

Prev Next

In This Thread

Prev Next