(´-`).。oO(イーデス・ハンソン……)
;y=ー( ゚д゚)・∵. ターン
イーデス・ハンソン≒半村 良
>>230 一通り要望も出たみたいだし、バージョン来てから考える
いやならネタを振ってくれ
俺は寝るけどな(w
∧ ∧ ∧ ∧
(#゚Д゚ ) ゴルァ! ( ´_ゝ`)フーン
─┬∪┬∪┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─┬─
┬┴┬┴┬┴┬┴┬┴┬┏━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┴┬┴┬┴┬┴┬┴┬┴┃ # ここは本スレ # ┃
┬┴┬┴┬┴┬┴┬┴┬┃ .┃
┴┬┴┬┴┬┴┬┴┬┴┃ # テスター以外は失せろ # .┃
┬┴┬┴┬┴┬┴┬┴┬ ┃
┴┬┴┬┴┬┴┬┴┬ ぴしっ☆ ━━━━━━━━━━━━━━━━━━┛
┬┴┬┴┬┴┬┴┬┴ ∧∧ /.) ☆ ┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬
┴┬┴┬┴┬┴┬┴┬ (゚ ) ) ( ぴしっ ┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴
┬┴┬┴┬┴┬┴┬┴ (| ,ノ ) ┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬
┴┬┴┬┴┬┴┬┴┬ 〜' | .┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴┬┴
─┴─┴─┴─┴─┴ U U .┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─┴─
>>135 ファイル名の最大256文字は取りすぎだと思う。
最大128文字にすれば、10000個のキーで10MBも減らせる。
ほとんどのファイル名が128文字以下にもかかわらず256byteを固定長で確保しているだろうから、
メモリの無駄が多すぎる。
デフォルト128文字、128文字を超えた分は、リファレンス入れて別バッファで管理しる。
というか、ファイル名なんて、
[アニメ][DVD]ほにゃらら 第01話、・・第02話、・・・第xx話みたいに
冗長度がむちゃくちゃ高いんだから、動的に辞書圧縮しる。
01:[アニメ]
02:[DVD]
03:ほにゃらら
04:第01話
05:第02話
01020304
01020305
平均32byte以下に抑えられると思うぞ。
ついでにキーワードによる検索に辞書を活用すれば、さらに高速になってウマー。
☆バグ報告用テンプレ v2.21(゚д゚)
☆--------------------------------------------------
☆【 OS/CPU/メモリ 】 WinXP SP1 / Athlon1800+ / 512 MBytes
☆【 使用回線 】 DSL8M
☆【 使用NIC 】 Realtek RTL8139
☆【 DDNS名 】 ---
☆【 回線速度 】 80 kBytes
☆【 Acceptポート番号 】 非7743
☆【 保持キャッシュサイズ 】 70 GBytes
☆【キャッシュドライブ空き容量】 4 GBytes
☆【ダウンドライブ空き容量 】 4 GBytes
☆【外部から接続不可能 】 未チェック
☆【検索リンク数/port0割合 】 6/0〜2
☆【仮想キー最大個数 】 20000
☆【 備考 】 回線の上下干渉が強い為、例のDLL(○○2 32.dll)使用
もちろんUP0パッチ等は使用しとりません (w
☆--------------------------------------------------
☆【 バグ症状 】 稀に空のUP転送リンクが切れなくなる(つまりDOM状態になる)
☆
☆【 バグ発生方法 】 放置中に起きる。v1.05.01とv1.05.03で各1回の再現を確認。
☆--------------------------------------------------
スクリーンショット
ttp://winny.info/fileboard/files/img20030120024319.jpg
>>236 おいおい、ちょっと頭いいこと書くとすぐ131扱いかよ。
そのうち
2ちゃんねらー向けOS作るから
ちょっとまってなー
とかいう人も出てきそうな勢いでしたね
>235
システム情報のキーバッファサイズの動き見てると
ファイル名の配列は動的に取ってると思うけどな・・・・。
キー数とサイズが正比例しないもん。
動的辞書圧縮は手だね。
>>238 すでに関心の薄れた内容を長々書くのが131風
おかしい。
ダウンロードが終わってもリストから消えない。
何でだ。
既に131と言う数字は47の対極として扱われているな。
ていうか、
計算しなおしたら最大128文字にしたって、10000個のキーで1.2MBしかへらねーじゃねーか。
一桁まちがってた。
でもさ、キー辺り6KBとか食ってる計算になるんだけど、何がそんなにメモリを食ってるんだ。
やっぱ検索系?
>>243 ダウン完了したらキー削除、ちゃんとチェックしてあるん?
手動で登録したやつで、チェックし忘れてたとかじゃないのか?
>>ID:AV2CtYVe
あにめとか流れてるってのは47氏は想定してない。(ことになっている)
おや、自己完結してるな。
じゃ、このネタ
===========糸冬了=============?
当店ではマジックマッシュルームを研究用として販売しております。
誤って食べてしまった場合に責任を取ることは出来ません。ご了承ください。
漏れの知ってるcgi-binって入ってるURLは大抵エロ画像だ
中身はともかく
動的辞書圧縮導入はキーの流通面では面白いアプローチだね。
各クラスタごとの協力が別個で必要だけど
>>249 そんなつれないこと言うなや。
ま、どうでもいいけどな。でもメモリ食いすぎ、異常。以上。
===========糸冬了=============。
>252
流通までやれるかな?
内部的になら、それほど大変じゃないけど・・・・。
キーの処理って重いんじゃなかったっけ?
さらに圧縮までかけちゃって大丈夫なん?
>255
圧縮って言っても、ハフマンとかやるわけじゃなくて
出現頻度の高いキーワードを辞書化するだけだから。
235の言うように、検索なんかはむしろ速くなるよ。
>>252 終了しといてなんだけど、俺もキー1個1個送るんじゃなくて、
最大256種類ぐらいのミニ辞書と、そのインデックスで構成されたキーを
まとめて送ったら結構帯域が節約できるんじゃないかと思ってる。
で、受け取った側は、ミニ辞書を内部辞書に加えて、インデックスを置換する。
でまた送る時は、内部辞書から送るキーに必要な最小限のミニ辞書を作って・・・・みたいな。
所詮は妄想だけど。
静的な辞書を組み込む、というアプローチはいくら効果的でも実装されないと思う。
>258
そりゃそうだ。動的でないといかん。色んな意味で。
>>258 辞書はユーザーが自分で登録する。
後は、他の相手と辞書を送りあって、勝手に辞書が膨らんでいくみたいなのはどう?
自動で作るのもありだけど、負荷がかかるし、あまり綺麗な辞書はできなさそうだし。
現在使用メモリ120Mか。今の倍使ってくれても全然かまわんが。
辞書とかそういった各ノードの傾向が明らかに出るものを
プロトコル上でやりとりするのは危険だと思われ。
というか、これだけキーがばしばし入れ替わるWinnyで辞書による変換をやるのは
ちょっと辛いんじゃないだろうか。
>260
それはよくない。
無駄な辞書ができる可能性もある。
>261
俺もそう。あと200MBくらい盛大に使われても平気。
>262
どの程度の効果/負荷なのかは神(47氏)のみぞ知る。だな。
(´ー`).。oO(そういえば大昔2GBまで頑張ったことがあったなぁ(w)
そんなメモリ使われるといまのユーザーの何割かが弾かれるよ。
512MBくらいのせてろってことでしょ。
>>262 辞書+圧縮したキーを送ろうが、似たキーワードいっぱいのキーを送ろうがかわらねーとは思うけどね。
それに辞書の動的最適化とかをやらん限り、辞書変換の負荷なんてたいしたことねーでしょ。
ま、でも256byteが32byteに減ったところで、数MB減るか減らないかなんで意味ねーわな。
でも、もし検索のためにメモリを大量に使ってるんだったら、辞書使えば結構効果はあるかもね。
ぐらいだね。
ま、結局最大128MBしかつめない俺のノートを買い換えたほうが早かったりするのだが。
64Mで、がんがってまつ
ノートなので増やせません
>266
いや、故意に無意味な文字列を登録して流されると・・・・
一文字をどんどん登録するとかってのはあらかじめ弾けるとしても。
ま、確かに焼け石に水な気がするけどね>圧縮
>>268 どっちにしろ、キーに使われていない文字列は送れないんで
ゴミ辞書で溢れるということにはならないと思うけど。
いや、でもゴミキーとゴミ辞書をペアで・・・・。
いや、でも使われてない辞書を消すようにすれば、ゴミキーを消したら同時に消えてくれるか・・・。
ま、現状のNYでは、焼け石に水なのは同意。
キャッシュが保持しているブロックマップをすべてのキー分持ってるとすると、
32768ブロック/8bitで4KBだから、計算が合うかも。
>>219 WinnyはRedMagicだったのか!
と遅すぎるレス。
>>270 それだ!
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE,RLE
と47氏が圧縮してくれるまで唱えてみる。
まぁ、処理を軽くするためにあらゆるフィールドを固定長にしてるんだろうな。
全くキャッシュに無いファイルは例外処理してほしいところだけど、
どれくらいオーバヘッド出るかなぁ。
ダウンが始まったら結局ブロックマックを確保しないといけなくなるわけだし。
>>273 もし仮にブロックマップをベタに保持しているのであれば、
それは処理を軽くするどころか、逆効果だと思う。(スワップで死にそう)
RLEで圧縮すれば、256byteでも十分すぎるのではないかと思うし、
もし仮に256byteを溢れるようなことがあったら、そのキャッシュを消して一からやりなおせば良いだけ。
ブロックマップなんて転送時ぐらいしか参照しないだろうから、動的にRLEで圧縮展開を繰り返してもゴミみたいな負荷だろうし。
RLEなら逆にブロック表示の速度も上がるだろうし。
てか、それだけで今のメモリ使用量が4分の1になるってのは夢みたい。
ぜひ考えてみてください>47氏
☆バグ報告用テンプレ簡略版 v2.22(゚д゚)
☆--------------------------------------------------
☆【 OS 】 XPsp1
☆【外部から接続不可能 】 可能
☆【 備考 】
☆--------------------------------------------------
☆【 バグ症状 】 スレッドの発言数が実際の発言数と不一致
☆
☆【 バグ発生方法 】 v1.05.03で掲示板を表示
☆--------------------------------------------------
>正式版1.05.01 → 正式版1.05.02
>・ 捏造警報を参照量の方に表示するようにした
たぶん、この修正のときからスレッドに警報表示が無くなってるので、
警報(無視)スレッドの発言数の表示変更を忘れてると思います。
>274
いかに展開しないかがポイントやね。
RLEとはいえ、フロントエンドに持ってきたらやっぱ負荷上がるし。
圧縮する方は、データが更新されるたびにやるしかないんだろうなぁ・・・・。
>>247 ダウン完了したらキー削除はチェックしてありまつ。
消えるときと消えないときがあります。
何か仕様が変わったのか、それともバグか。
手動で消すのは面倒過ぎる。
>>278 ダウンロード完了→キャッシュから変換完了、この一連の作業でリストから消える
ダウンロード完了後キャッシュから変換が終わらないうちにnyが終了した場合
ny再起動してキャッシュから変換してもリストから消えない
既出かな?
★--------------------------------------------------
★【 要望 】スクロールバーを右クリックしたときに
★ スクロールバー用のメニューが出るようにしてほしい
★【 メリット 】いや、なんとなく気持ち悪くて。
★【デメリット】使う人があまりいなそう。
★--------------------------------------------------
ついでにもうひとつ
★--------------------------------------------------
★【 要望 】ファイル検索時やキャッシュ変換時に
★ 文字列の置換を適用できるようにしてほしい
★ a -> A 、( -> [ 、test -> テスト みたいに
★ (ただし、キー情報は変更せずに)
★【 メリット 】検索、管理がしやすくなる。
★【デメリット】処理が重そう。
★ 意図しなかった変なファイル名ができるかも。
★ ファイル名に対する意識が低くなる。
★--------------------------------------------------