[mhc:00679] TSU_SPEED のマージの前に

[Yoshinari NOMURA <nom@xxxxxxxxxxxxxxxxxxx>]

乃村です。TSU_SPEED 枝マージの前に。

土屋さんのスケジュールの検索方式について、
ちょっと質問です。a月b日のスケジュール (dayinfo) を作るのに、
それぞれのスケジュールに S式を評価させて、true/false を
返させているのですよね。

すると、x日分で y個のスケジュールがあると、
x * y で効いてきませんか?
intersect/ がどのぐらいまで耐えられるのだろう。

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

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

tree に入れてしまえば、a月b日のデータを調べるのはほぼ定数時間で
すので x だけが factor になります。

# 現行の mhc が遅いのは、僕のいいかげんな elisp とか、そういった
# 部分のせいですね。
# 実は、byte-compile しなれば、ほぼ同じ実行時間ではないですか?

試しに .schedule を 26個 cat して
C-c. で一度データを作らせておいて、
C-c. を 1回やってみると、速度は逆転しました。
(TSU_SPEED は bytecompile したもの。幹の物は .el のまま。)

# 実は、前に土屋さん方式と同じように書いてみたら、
# 僕の elisp の能力が原因で、遅くて使い物にならなかったのでした。^^;

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

とはいえ、僕の方式は、日付を静的に表現できないと tree に入れられ
ないので、x月y日から n 日毎というスケジュールには有効ではありません。
ので、土屋方式は今後のために必須です。それに、parse がめちゃ速い。

S式と X-SC-Schedule: のサポート後、先々 slot の切り方等を
もう一度考えたり、(ほとんどのスケジュールは静的日付けで書けるので、)、
両者の併用を検討する必要が先々出て来そうですが、実際の使用上問題
が出るかどうかは、少し見守る必要がありそうです。

# それにしても、土屋さんのコードは十分速いので、杞憂かもね。
--
nom

p.s. calendar.el も、同じようなことをいっています。静的に書けな
     い物は、S式でカバーするけど、これを使うとめちゃ重いので覚悟
     しろと。。