[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[mhc:00680] Re: TSU_SPEED のマージの前に

>> On Thu, 1 Jun 2000 15:10:48 +0900
>> "nom" == nom@xxxxxxxxxxxxxxxxxxx (Yoshinari NOMURA) said as follows:

nom> すると、x日分で y個のスケジュールがあると、
nom> x * y で効いてきませんか?

YES.

nom> intersect/ がどのぐらいまで耐えられるのだろう。

それは分かりませんが、byte-compile した関数が呼び出されるように工夫し
ているので、相当程度には耐えられるはずです。


nom> 僕の方法は、それだと辛そうだったので、
nom> parse した時点で tree に入れています。

nom> -2nd +- Tue -(schedule1 schedule2 schedule3)
nom>      +- Wed -(schedule4 schedule1)

はい、この方式を理解した上で、それでも検索が高速になるから大丈夫だろう
と思って、実装が楽な方を取りました。


nom> # 実は、byte-compile しなれば、ほぼ同じ実行時間ではないですか?

ええっ? そうかなぁ、私の手元の計測では双方ともに byte-compile しない状
態でも2倍くらい違うんですけど…。

# 確かに、私のコードは defmacro / defsubst で実行速度を稼いでいる点は
# 否めません。


nom> 試しに .schedule を 26個 cat して
nom> C-c. で一度データを作らせておいて、
nom> C-c. を 1回やってみると、速度は逆転しました。

ということは、理論上は intersect/ に 18 * 26 = 468 個のスケジュールを
置くと逆転すると予想されますね。

これって、かなり十分な数だと思うんですけど。


nom> X-SC-Schedule: の導入によって intersect/ に入る率が増えそうで、
nom> ちょっと心配です。

これは以前にも提案しましたが、

    2000/intersect
    2000/04
    2000/04
    ...
    2001/intersect
    ...
    intersect/

という切り分けで、ある程度対処できるのではないでしょうか。


-- 
土屋 雅稔  ( TSUCHIYA Masatoshi )
    http://www-nagao.kuee.kyoto-u.ac.jp/member/tsuchiya/