■スレッドリストへ戻る■ 全部 1- 101- 201- 301- 401- 501- 601- 701- 801- 901- 最新50
read.cgi改良スレッド
- 736 ：デフォルトの名無しさん ：01/09/07 10:45
- 以下は名無し娘。さんのお手伝い・・・のつもり。
>#ifdef の字面と内容が噛み合わない部分
-DCUTRESLINKは、本当に#define名と内容が一致していない。
変更部のメインは最適化で、リンクの削除はオマケ程度な感じ。
方向としては、
・mmapがSHARED & READONLYで使えるようにBigBufferを読みこみだけに
・ファイル全体やレス全体を走査する回数を極力減らす
・そのために変換や空白削除、http://のリンク等を全て同時に行う
といったところ。
ただ、そのことにより内部で保持するデータ形式が変わってしまい、
他の部分への影響も出ている。
名目通りのCUTRESLINKに相当するのは大きなswitch文の一箇所だけで
全体のdefine名は、つけ直すならBUFFER_READONLYとか
NO_RES_NUL_TERMINATEとか、そんな感じに近いと思う。
>replace系の関数を最適化する方が
上とも関連するけど、現在、-DCUTRESLINKを指定すると
replace系は全く使われない。
現行のVer5.12等では、hlinkReplaceの中でdoReplaceが使われているが、
これもressplitter_splitの内部に吸収されている。
ソース中ではTYPE_TERIが定義されていない場合にsomeReplaceが呼ばれるが、
同等の変換は既にressplitter_split内部で為されているので、本来必要ない。
というわけで、-DCUTRESLINK(内容は違う)を採用する方針でいくなら、
replace系には目を向けなくてもいいと思う。
あえて不安材料を挙げれば、Ver5.1xでの稼動実績があるのが基本部だけで、
保持データ系式の変更やhttp://リンク、mmapとの併用、
これらでの実績が乏しい点があるが、今のところ
まともなdatを低負荷時に読んでいる範囲では、問題は出ていない。
逆に、-DCUTRESLINKを採用しない/条件等によっては機能をoffにしたい、
となる可能性があるなら、replace系の最適化には意味がある。
その辺の判断と指示はまとめ役の人にお任せしたい。
333KB
新着レスの表示
スレッドリストへ戻る 全部 前100 次100 最新50
0ch BBS 2004-10-30