私設SoS2オーナー応援BBS

新規発言一覧最新記事過去一覧検索ダウンロードページHOME

スレッド

└◇744:
rateについて気付いた、どうでも良いこと [moon] 08/24 17:34

 └◇745:Re:rateについて気付いた、どうでも良いこと [masaki] 08/25 16:58
  └◇746:Re[2]:rateについて気付いた、どうでも良いこと [masaki] 08/25 16:59
   └◇747:Re[3]:rateについて気付いた、どうでも良いこと [moon] 08/25 19:15
    └◇748:ちょっと話が変わりますが [masaki] 08/25 20:05
     └◇749:負荷軽減案、いろいろ [moon] 08/25 23:42
      └◇750:Re:負荷軽減案、いろいろ [masaki] 08/26 07:39
       └◇751:Re[2]:負荷軽減案、いろいろ [moon] 08/26 09:04
        └◇752:Re[3]:負荷軽減案、いろいろ [masaki] 08/27 09:42
         └◇755:Re[4]:負荷軽減案、いろいろ [moon] 08/27 20:24
          └◇760:Re[5]:負荷軽減案、いろいろ [masaki] 08/30 15:58<-last


744● rateについて気付いた、どうでも良いこと[ moon ] 2003 08/24 17:34
sub rateを実行する条件がif($wn)などのように勝利数が0でないか、なので勝利数が0のままだと計算式で意図したrate値が得られないですね。
例えば、デフォルトだと勝0敗10死10のプレイヤーと勝1敗9死9のプレイヤーだと0対-890で前者のほうが高いrateになってしまいます。(後者のほうが勝利数が多く死亡数も少ないのに。)
気になる人は修正してみてはどうでしょう。

# 自分の初見の事柄だったので情報提供として書いてみました。
# 情報の実用度はほぼゼロですが。(笑)
スレッド一覧


745● Re:rateについて気付いた、どうでも良いこと[ masaki ] 2003 08/25 16:58
> sub rateを実行する条件がif($wn)などのように勝利数が0でないか、なので勝利数が0のままだと計算式で意図したrate値が得られないですね。
> 例えば、デフォルトだと勝0敗10死10のプレイヤーと勝1敗9死9のプレイヤーだと0対-890で前者のほうが高いrateになってしまいます。(後者のほうが勝利数が多く死亡数も少ないのに。)
> 気になる人は修正してみてはどうでしょう。
>
> # 自分の初見の事柄だったので情報提供として書いてみました。
> # 情報の実用度はほぼゼロですが。(笑)
うちのもそうなっているのかな(変更していないからなってますw)
最初のうちは気になるかもしれませんね。。
もし修正するなら
if($wn)

if($wn||$lz)
でしょうか?(^^;
なぜこんなところに気づいたのでしょうか?w
そっちのほうが気になったりします(^^;
スレッド一覧


746● Re[2]:rateについて気付いた、どうでも良いこと[ masaki ] 2003 08/25 16:59
> なぜこんなところに気づいたのでしょうか?w
> そっちのほうが気になったりします(^^;
不遇の戦士の表示のときですか?(^^
スレッド一覧


747● Re[3]:rateについて気付いた、どうでも良いこと[ moon ] 2003 08/25 19:15
> if($wn)
> を
> if($wn||$lz)

修正箇所の少なさだとこれなのですが、個人的にはこの部分のifを取り払ってしまってsub rateを修正したほうが良いような気がします。
そうすれば、rateを実行する処理を今後追加したとしてもif無しで呼び出せるので余計なことを考えずに済むので。

> > なぜこんなところに気づいたのでしょうか?w
> > そっちのほうが気になったりします(^^;
> 不遇の戦士の表示のときですか?(^^

ビンゴです。(笑)
スレッド一覧


748● ちょっと話が変わりますが[ masaki ] 2003 08/25 20:05
先ほど久々にモンスターに襲われたのですが、以前と表示が違うような。(^^(気のせい?)


自分のSoSやってからSoSMeをやると、スピードの違いに悲しくなります(泣)
分割する以外に軽くする方法とかあるのですか??
よく行われるところは分割しないほうがいい。とどこかで見ましたが。(^^;
スレッド一覧


749● 負荷軽減案、いろいろ[ moon ] 2003 08/25 23:42
> 先ほど久々にモンスターに襲われたのですが、以前と表示が違うような。(^^(気のせい?)

何も触っていないので気のせいだと思います。

> 自分のSoSやってからSoSMeをやると、スピードの違いに悲しくなります(泣)

まあ、一応有料サーバなので逆に重いとお金を払ってまで借りている意味が・・・。
# と言っても最初いたbig.or.jpのwww25サーバは依然として混みまくっているようですが。(本当に移って良かった。)

> よく行われるところは分割しないほうがいい。とどこかで見ましたが。(^^;

本家BBSでそう答えたことがありますが、その時は理由を省略していたので一つの意見としてのメリットデメリットを書いておきます。
メリット : ファイルアクセスが最低1回は少なくなるのでHDのシークにかかる時間が少なくなる。
デメリット : 分割していないので実行ごとのメモリ使用量は変わらない。

> 分割する以外に軽くする方法とかあるのですか??

ここで過去話題にしたやり方に加えて、その他のアイディアを書いておきます。

・rateの負荷軽減になることを期待したいやり方。(アップしていないけれど実装済み)
  sub rateを、
    sub rate{
    return $_[0] + $_[1] ? (int($_[0] / ($_[0] + $_[1]) * 100) * $_[0] + $_[2] * 100 - $_[3] * 100) : ($_[2] * 100 - $_[3] * 100);
    # もしくはさらに進んで、
    # return $_[0] + $_[1] ? (int($_[0] / ($_[0] + $_[1]) * 100) * $_[0] + ($_[2] - $_[3]) * 100) : (($_[2] - $_[3]) * 100);
    # 無駄な括弧は気分で付けただけなので無くても大丈夫だと思います。
  }

・get_userやget_partnerの負荷軽減(そのうち変更したいけれどまだ未実装)
  if($_[0]){
    # (1)ユーザデータだけを1行読み込む処理
  }
  else{
    # (2)通常の処理(ユーザデータをマイレコードを含めて配列に読み込む)
  }
  というように2つに分け用途に応じて、
    その後にユーザデータを保存する処理が無い場合 &get_user(1); → (1)
    ユーザデータを保存する場合 &get_user; → (2)
  と使い分ける。

・以前、本家BBSに書いて一つもレスが無かったやり方。(実装できないので未実装)
  > 複数回探索って毎ループで、見つかるアイテムの判定を全てのアイテムに対して行っていますよね。(毎回確率をランダムにしていると思うので)
  > それは、なんか無駄処理なので処理量軽減案を考えてみました。
  >
  > ループの外で以下を実行。
  >   @itemlines = sort {(split(/<>/,$b))[2]<=>(split(/<>/,$a))[2]} @itemlines; # 出現確率を降順に並べ替え
  > ループの中でforeach $item (@itemlines){〜}の周辺を以下のような感じに変更。
  >   @founditems = ();
  >   foreach $item (@itemlines){
  >     ($inm,$idt,$idc) = split(/<>/,$item);
  >     if($rnd<=$idc){
  >       push(@founditems,$item);
  >     }
  >     else{
  >       last;
  >     }
  >   }
  >
  > こうすることにより、処理量が下がるので負担が減るだろうと思います。
  >
  > # 案なので根本的な間違いや抜けているところがあるかもしれません。
  > # しかも、自分ではテストさえしていません。
  少し説明を付け加えると、「出現確率を降順に並べ替え」はあらかじめitm.datを並べ替えておけばする必要自体がなくなります。
  問題点としては、他の改造によって取り入れることが出来ない、出現アイテムが偏る可能性がある、があります。

・ディレクトリ走査の減少による負荷軽減策(実装済み)
  うちで実装されているものとはかなり異なりますが、基本コンセプトが同じだと思われるものがSAIL/SIONさんのHPで最高星数の改造として公開されています。

# 既にうちで実装済みのものであろうともここに書き出し時や元からミスがある可能性があるので参考程度にしてください。

----

負荷軽減案ではないですけれど、以前本家BBSに書いてこれもレスが無かったステラ処理。
  > ステラツィオトレードのバグ(Ver.1.10時点)を出きるだけ取り除いたものを考えてみました。
  > ついでに新たに手に入れたステラツィオが既に所持しているものなら、トレード設定になるようにしています。
  > 以下全文掲載。
  >
  > # ここから(タブの代わりに全角空白2つを使用)
  > sub trade_after{
  >   if(!$Fm{'P'}){push(@msg,'相手のステラツィオが選択されていません'); return;}
  >   if(!$Fm{'U'}){push(@msg,'あなたのステラツィオが選択されていません'); return;} # 自分の選択確認
  >   $Fm{'P'} = lc(substr($Fm{'P'},0,1)); # 選択を一つにし小文字に
  >   $Fm{'U'} = substr($Fm{'U'},0,1); # 選択を一つに
  >   if($Fm{'P'} eq lc($Fm{'U'})){push(@msg,'同じステラツィオはトレード出来ません'); return;} # 同じ場合は弾く
  >   @rcdlines = &get_user("$Fm{'id'}");
  >   @prclines = &get_partner("$Fm{'pd'}");
  >   return if($fg ne 'TB');
  >   if(index($pis,$Fm{'P'})<0){push(@msg,'相手は選択したステラツィオをトレードに出していません'); return;} # トレードに出されているかの確認(indexがポイント)
  >   if(index($is,$Fm{'U'})<0){push(@msg,'あなたは選択したステラツィオを所持していません'); return;} # 選択したものを所持しているかの確認(同上)
  >   $is =~ s/$Fm{'U'}//; $is .= $is =~ /$Fm{'P'}/i ? $Fm{'P'} : uc($Fm{'P'}); # 交換後のステラツィオが既に所持しているものなら交換に出す設定にする
  >   $pis =~ s/$Fm{'P'}//; $pis .= $pis =~ /$Fm{'U'}/i ? lc($Fm{'U'}) : uc($Fm{'U'}); # 同上
  >   $fg = '';
  >   &userout;
  >   &add_record("[$id] $nmがあなたとステラツィオをトレードしました");
  >   push(@msg,'ステラツィオをトレードしました');
  > }
  > # ここまで
  >
  > 設置してあるものから不必要な部分を削除した時に文法的なミスが出たかもしれませんが、そこのところは修正してください。
  > あと、バグの内容については直接は触れません。(笑)
スレッド一覧


750● Re:負荷軽減案、いろいろ[ masaki ] 2003 08/26 07:39
> > 先ほど久々にモンスターに襲われたのですが、以前と表示が違うような。(^^(気のせい?)
>
> 何も触っていないので気のせいだと思います。
>
> > 自分のSoSやってからSoSMeをやると、スピードの違いに悲しくなります(泣)
>
> まあ、一応有料サーバなので逆に重いとお金を払ってまで借りている意味が・・・。
> # と言っても最初いたbig.or.jpのwww25サーバは依然として混みまくっているようですが。(本当に移って良かった。)
>
> > よく行われるところは分割しないほうがいい。とどこかで見ましたが。(^^;
>
> 本家BBSでそう答えたことがありますが、その時は理由を省略していたので一つの意見としてのメリットデメリットを書いておきます。
> メリット : ファイルアクセスが最低1回は少なくなるのでHDのシークにかかる時間が少なくなる。
> デメリット : 分割していないので実行ごとのメモリ使用量は変わらない。
>
> > 分割する以外に軽くする方法とかあるのですか??
>
> ここで過去話題にしたやり方に加えて、その他のアイディアを書いておきます。
>
> ・rateの負荷軽減になることを期待したいやり方。(アップしていないけれど実装済み)
>   sub rateを、
>     sub rate{
>     return $_[0] + $_[1] ? (int($_[0] / ($_[0] + $_[1]) * 100) * $_[0] + $_[2] * 100 - $_[3] * 100) : ($_[2] * 100 - $_[3] * 100);
>     # もしくはさらに進んで、
>     # return $_[0] + $_[1] ? (int($_[0] / ($_[0] + $_[1]) * 100) * $_[0] + ($_[2] - $_[3]) * 100) : (($_[2] - $_[3]) * 100);
>     # 無駄な括弧は気分で付けただけなので無くても大丈夫だと思います。
>   }
>
> ・get_userやget_partnerの負荷軽減(そのうち変更したいけれどまだ未実装)
>   if($_[0]){
>     # (1)ユーザデータだけを1行読み込む処理
>   }
>   else{
>     # (2)通常の処理(ユーザデータをマイレコードを含めて配列に読み込む)
>   }
>   というように2つに分け用途に応じて、
>     その後にユーザデータを保存する処理が無い場合 &get_user(1); → (1)
>     ユーザデータを保存する場合 &get_user; → (2)
>   と使い分ける。
ここがよくわからないのですが、(1)の処理というのはどのようなものでしょうか?(^^;
(2)はこのへんでしょうか??(汗
    open(IN,"$usrdir$_[0]\.dat") || &error("ID $_[0]は存在しません");
    @_ = <IN>;
    close(IN);
    if (!@_) { &error("読みこみエラー") }
    ($id,$nm,$ps,$jb,$ig,$sp,$bp,$bn,$ak,$dd,$hp,$xp,$ab,$db,
    $av,$wn,$lz,$dt,$mn,$bg,$xi,$tm,$lf,$fe,$cm,$is,$ht,$fg,$rw,$kl,$tw,$cs,$sg,$msgcount,$el,$mym,$Dg,$Dm) = split(/<>/,$_[0]);
>
> ・以前、本家BBSに書いて一つもレスが無かったやり方。(実装できないので未実装)
>   > 複数回探索って毎ループで、見つかるアイテムの判定を全てのアイテムに対して行っていますよね。(毎回確率をランダムにしていると思うので)
>   > それは、なんか無駄処理なので処理量軽減案を考えてみました。
>   >
>   > ループの外で以下を実行。
>   >   @itemlines = sort {(split(/<>/,$b))[2]<=>(split(/<>/,$a))[2]} @itemlines; # 出現確率を降順に並べ替え
>   > ループの中でforeach $item (@itemlines){〜}の周辺を以下のような感じに変更。
>   >   @founditems = ();
>   >   foreach $item (@itemlines){
>   >     ($inm,$idt,$idc) = split(/<>/,$item);
>   >     if($rnd<=$idc){
>   >       push(@founditems,$item);
>   >     }
>   >     else{
>   >       last;
>   >     }
>   >   }
>   >
>   > こうすることにより、処理量が下がるので負担が減るだろうと思います。
>   >
>   > # 案なので根本的な間違いや抜けているところがあるかもしれません。
>   > # しかも、自分ではテストさえしていません。
>   少し説明を付け加えると、「出現確率を降順に並べ替え」はあらかじめitm.datを並べ替えておけばする必要自体がなくなります。
>   問題点としては、他の改造によって取り入れることが出来ない、出現アイテムが偏る可能性がある、があります。
>
> ・ディレクトリ走査の減少による負荷軽減策(実装済み)
>   うちで実装されているものとはかなり異なりますが、基本コンセプトが同じだと思われるものがSAIL/SIONさんのHPで最高星数の改造として公開されています。
>
> # 既にうちで実装済みのものであろうともここに書き出し時や元からミスがある可能性があるので参考程度にしてください。
>
> ----
>
> 負荷軽減案ではないですけれど、以前本家BBSに書いてこれもレスが無かったステラ処理。
>   > ステラツィオトレードのバグ(Ver.1.10時点)を出きるだけ取り除いたものを考えてみました。
>   > ついでに新たに手に入れたステラツィオが既に所持しているものなら、トレード設定になるようにしています。
>   > 以下全文掲載。
>   >
>   > # ここから(タブの代わりに全角空白2つを使用)
>   > sub trade_after{
>   >   if(!$Fm{'P'}){push(@msg,'相手のステラツィオが選択されていません'); return;}
>   >   if(!$Fm{'U'}){push(@msg,'あなたのステラツィオが選択されていません'); return;} # 自分の選択確認
>   >   $Fm{'P'} = lc(substr($Fm{'P'},0,1)); # 選択を一つにし小文字に
>   >   $Fm{'U'} = substr($Fm{'U'},0,1); # 選択を一つに
>   >   if($Fm{'P'} eq lc($Fm{'U'})){push(@msg,'同じステラツィオはトレード出来ません'); return;} # 同じ場合は弾く
>   >   @rcdlines = &get_user("$Fm{'id'}");
>   >   @prclines = &get_partner("$Fm{'pd'}");
>   >   return if($fg ne 'TB');
>   >   if(index($pis,$Fm{'P'})<0){push(@msg,'相手は選択したステラツィオをトレードに出していません'); return;} # トレードに出されているかの確認(indexがポイント)
>   >   if(index($is,$Fm{'U'})<0){push(@msg,'あなたは選択したステラツィオを所持していません'); return;} # 選択したものを所持しているかの確認(同上)
>   >   $is =~ s/$Fm{'U'}//; $is .= $is =~ /$Fm{'P'}/i ? $Fm{'P'} : uc($Fm{'P'}); # 交換後のステラツィオが既に所持しているものなら交換に出す設定にする
>   >   $pis =~ s/$Fm{'P'}//; $pis .= $pis =~ /$Fm{'U'}/i ? lc($Fm{'U'}) : uc($Fm{'U'}); # 同上
>   >   $fg = '';
>   >   &userout;
>   >   &add_record("[$id] $nmがあなたとステラツィオをトレードしました");
>   >   push(@msg,'ステラツィオをトレードしました');
>   > }
>   > # ここまで
>   >
>   > 設置してあるものから不必要な部分を削除した時に文法的なミスが出たかもしれませんが、そこのところは修正してください。
>   > あと、バグの内容については直接は触れません。(笑)
色々ありますね(^^
試してみたいとおもいます。(わからないところが多いですがw)
(ドラゴンテンペストが想像以上に重いです(泣))
スレッド一覧


751● Re[2]:負荷軽減案、いろいろ[ moon ] 2003 08/26 09:04
> ここがよくわからないのですが、(1)の処理というのはどのようなものでしょうか?(^^;
> (2)はこのへんでしょうか??(汗
>     open(IN,"$usrdir$_[0]\.dat") || &error("ID $_[0]は存在しません");
>     @_ = <IN>;
>     close(IN);
>     if (!@_) { &error("読みこみエラー") }

(2)はsub get_userの@_ = <IN>;からreturn @_;までです。
そして、(1)は読み込み部分を$userline = <IN>;のように1行だけ読み込むようにしマイレコード部分は読み込まないようにします。
# (1)を実行したにも関わらず間違って&userout;をしてしまうとマイレコードが消えてしまうので注意。
考えられるメリットデメリットは、
・メリット : メモリ使用量、HDアクセスの減少
・デメリット : ifの判定が1つ多くなるだけ

---- 昨日書いたことの訂正 ----

> # もしくはさらに進んで、
> # return $_[0] + $_[1] ? (int($_[0] / ($_[0] + $_[1]) * 100) * $_[0] + ($_[2] - $_[3]) * 100) : (($_[2] - $_[3]) * 100);
> # 無駄な括弧は気分で付けただけなので無くても大丈夫だと思います。

デフォルトのように殺害数や死亡数が勝利数と敗北数が0だと必ず0なら、: (($_[2] - $_[3]) * 100)は: 0でもOK。

> メリット : ファイルアクセスが最低1回は少なくなるのでHDのシークにかかる時間が少なくなる。

分割した場合、と比べてのメリットです。

> 基本コンセプトが同じだと思われるもの

実際、同じということは無いと思うので「似たようなもの」に訂正。
スレッド一覧


752● Re[3]:負荷軽減案、いろいろ[ masaki ] 2003 08/27 09:42
> > ここがよくわからないのですが、(1)の処理というのはどのようなものでしょうか?(^^;
> > (2)はこのへんでしょうか??(汗
> >     open(IN,"$usrdir$_[0]\.dat") || &error("ID $_[0]は存在しません");
> >     @_ = <IN>;
> >     close(IN);
> >     if (!@_) { &error("読みこみエラー") }
>
> (2)はsub get_userの@_ = <IN>;からreturn @_;までです。
> そして、(1)は読み込み部分を$userline = <IN>;のように1行だけ読み込むようにしマイレコード部分は読み込まないようにします。
> # (1)を実行したにも関わらず間違って&userout;をしてしまうとマイレコードが消えてしまうので注意。
> 考えられるメリットデメリットは、
> ・メリット : メモリ使用量、HDアクセスの減少
> ・デメリット : ifの判定が1つ多くなるだけ
呼び出すときは、&get_user("$Fm{'id'}");をどのように変えればいいのでしょうか??(^^;
質問ばかりですみません。。
スレッド一覧


755● Re[4]:負荷軽減案、いろいろ[ moon ] 2003 08/27 20:24
> 呼び出すときは、&get_user("$Fm{'id'}");をどのように変えればいいのでしょうか??(^^;
> 質問ばかりですみません。。

すみません。勘違いをしていました。
正しくは、
  if($_[1]){ # 0ではなく1
    # (1)
  }
  else{
    # (2)
  }
です。
そして、呼び出す場合は、
  &get_user($Fm{'id'});
および、
  &get_user($Fm{'id'}, 1);
で大丈夫だと思います。
スレッド一覧


760● Re[5]:負荷軽減案、いろいろ[ masaki ] 2003 08/30 15:58
> > 呼び出すときは、&get_user("$Fm{'id'}");をどのように変えればいいのでしょうか??(^^;
> > 質問ばかりですみません。。
>
> すみません。勘違いをしていました。
> 正しくは、
>   if($_[1]){ # 0ではなく1
>     # (1)
>   }
>   else{
>     # (2)
>   }
> です。
> そして、呼び出す場合は、
>   &get_user($Fm{'id'});
> および、
>   &get_user($Fm{'id'}, 1);
> で大丈夫だと思います。
やってみました(^^;
返信遅れてすみません。
軽くなった(ような?)気がします(汗
ありがとうございました!
スレッド一覧

CGIROOM