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

Re: w3m-hist.el 

>>>>> In [emacs-w3m : No.00390] 
>>>>>	Katsumi Yamaoka <yamaoka@jpl.org> wrote:

土屋さん> arrived DB => URL によって指定されるページの内容が変更されな
土屋さん>               い限り、変動しない諸々の要素(ファイルサイズ・
土屋さん>               更新日時など)を記録しておく。

土屋さん> history DB => emacs-w3m の起動・停止や、その動作によって変動
土屋さん>               する相対的な要素を記憶しておく。

土屋さん> というように役割分担すればすっきりするだろうと考えているので
土屋さん> すが、どうでしょうか。

山岡> そうですね。いずれも非常に大きな DB になる可能性があるものですか
山岡> ら、巨大なものを一つ作るよりは分けた方が良いのでしょうね。ぼくは
山岡> internal なことはわからないのですが、例えば同一構造の sequence
山岡> でも、やはりサイズが大きいほど負荷が重くなるのでしょうか?

これに関してぼくの想像を書きます。おそらく多くの方にとっては釈迦
に説法でしょうけれども、まずは前置きから。

(let* ((a "Hello World.")
       (b a))
  (eq a b))
 => t

ふつう文字列の比較には `string-equal' を使いますよね。ここでは
`eq' を使っています。そして結果は `t' です。「え? そんなアホな」
と思われた方は試してみて下さい。:-)

もう一つ。

(let* ((x (list 1 (vector "2" (cons (current-buffer) ?3) '(?4))))
       (y x))
  (eq x y))
 => t

ここで `x' は `(1 ["2" (#<buffer "*scratch*"> . ?3) (?4)])' とい
うこみ入った値ですが、やはり `eq' で比較した結果は `t' です。
実はこれらの実験は、ぼくが sequence という object の意味を理解す
るきっかけになったものです。さらにもう二つ例を。

(let ((a "Hello World.")
      (b "Hello World."))
  (eq a b))
 => nil

これ↑はそんなに昔ではない以前に、ぼくが文字列比較とはこういうも
のだと思っていたことです。

(let* ((x (list 1 (vector "2" (cons (current-buffer) ?3) '(?4))))
       (y x))
  (setcar y 999)
  x)
 => (999 ["2" (#<buffer "*scratch*"> . ?3) (?4)])

ぼくの経験やいろんな文献によれば、"Hello"、(1 2 3)、[?p ?q ?r]
といった sequence の単位は、Emacs の内部的には共有資源になります。
すなわち上記の例で `x' と `y' は二つの独立した変数シンボルですが、
実質は単一の資源を共有しているということです。

次に、これら sequence の単位を要素に持つ構造体を考えてみます。

(let ((i (list 1 2))
      (j (list 3 4))
      k)
  (setq k (list i j)))
 => ((1 2) (3 4))

この例で `k' は小さな内容物しか持っていませんが、もっと大きなも
のを想像してみて下さい。ここで `k' というリストのリストは、見た
ままの巨大なデータの集合なのでしょうか?

否、ぼくはこれは「二つのリストの組合せ」という sequence の構造を
示すだけのものだと思うのです。ここから本題に入りますが、w3m にお
ける木構造の history もそういうものなのではないでしょうか?
つまり、history 構造体に含まれる一つの要素が、訪問したことがある
web page の address だけでなく雑多な大量の付帯情報を持っていたと
しても、history 構造体は単なる骨格であって、意味のある contents
は Emacs の共有資源として別の場所に存在している、と考えるのは間
違っていないと思うのです。だとすれば、広義における history DB に
どんなに膨大な情報を持たせたとしても、その中のある要素をアクセス
するのが重い負荷になるかどうかは、情報の量ではなくて構造の複雑さ
にのみ関係するはずです。

そこで、ぼくはまず単一 (*) の history 構造体ですべてを管理するシ
ステムを作ってみようと思うのですが、いかがでしょう?
「いや、それは違う」という指摘をいただければ、むしろ無駄手間を省
けて嬉しいことなのですが。

;; 無駄手間になったとしても趣味として楽しみこそすれ苦痛であろう
;; はずはないから構わないのですけれどね。:-)

(*) すでに単一ではなくて二本立てになっていますが、`w3m-history'
    と `w3m-history-flat' それぞれの主な要素は共有資源になってい
    ます。なっているかな? 確認しなくちゃ...。
-- 
Katsumi Yamaoka <yamaoka@jpl.org>