Twitter Logview : @gorry5 : [Mention] : 2013/11/13

11/13 00:03 (@RetroComPeople) @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEARで確保されるのは文字列の実体を格納するエリアのバイト数だったはず。（続 (hige)

11/13 00:03 (@akikawa134) @Ackieee @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 文字列全体です。ただしREAD-DATAと直接代入分はプログラムアドレスを直接指すので領域を消費しないようです(テクノウより) (higo)

11/13 00:03 (@RetroComPeople) @RetroComPeople @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 ストリングディスクリプタは４バイト×要素数分が単純変数領域に確保される (hiza)

11/13 00:08 (@Ackieee) @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 ん，それはCLEAR100とやってA$,B$,C$を定義するとスタックの100バイトx3を消費するのであってますか? (hute)

11/13 00:13 (@akikawa134) @Ackieee @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEAR100→文字列領域100バイト確保、A$,B$,C$定義→変数領域の4バイトずつ(文字数とポインタ)×3確保です。 (hudo)

11/13 00:13 (@RetroComPeople) @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEARは文字列の実体を保存する領域全体のサイズなので、それでおｋですね。 (huba)

11/13 00:13 (@Ackieee) @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 理解できました。ありがとうございます。領域が狭い中で同一文字変数を何度も使うとGCが頻繁に起こりますね。なるほど。 (hubi)

11/13 13:05 (@tiny_yarou) @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @Lindberg1999 @SOW74656 あらかじめ"RESTORE行番号"を入れておくとちょっと速くなったりして。 (tadu)

11/13 13:06 (@Lindberg1999) @tiny_yarou @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @SOW74656 最初の頃、RESTOREだけ入れてましたが、取ってもタイム変わらなかったので外しました。直接指定すると変わるかも。 (tapa)

11/13 13:36 １ヶ月前の東京は30℃超えてたということをもう忘れそうだな…ｗ

11/13 14:38 (@tiny_yarou) @Lindberg1999 @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @SOW74656 READ文は&HFF5C,5Dに書かれているアドレスからDATA文を探していくのでRESTORE行番号で先にセットしておくと早 (nora)

11/13 15:06 とあるAndroidのL-06CがgetRefreshRate()で60.0(Hz)と返しながら実測58Hzだったり、Acer A500が同じく60.0で実測61Hzだったりしてひどい…（苦笑

11/13 15:15 (@shinsan68k) @gorry5 タイマーのほうがおかしいとかあったりしないかな (heki)

11/13 15:20 @shinsan68k 60Hzが58Hzというと誤差3%以上ですが、分単位で計測してるタイマーの誤差が3%以上もあったらえらいこっちゃ… (hemi)

11/13 15:21 (@shinsan68k) @gorry5 負荷によってCPUクロックが変わっておかしくなるとか昔あったなぁみたいな。

11/13 15:24 @shinsan68k リフレッシュレートはCPUクロックに依存しない（そもそも外部デバイスからの割り込みで成立する）ものなので :D

11/13 15:24 (@shinsan68k) @gorry5 いや、タイマー側の話ね。計測しているのが実機のタイマーかなぁと (hosi)

11/13 15:33 @shinsan68k タイマーもRTC（のはず）なので、CPUの外側ですわね

11/13 18:41 (@KAW6001) @tiny_yarou @Lindberg1999 @Ackieee @akikawa134 @beautyplanets @gorry5 @SOW74656 データを1行最大71文字で3行に詰め込むと、READの行番号サーチ回数が減る分速くならないかな…今試せないけど。 (danu)

11/13 19:11 (@tiny_yarou) @KAW6001 @Lindberg1999 @Ackieee @akikawa134 @beautyplanets @gorry5 @SOW74656 以前試した時は行数を減らしても効果は感じられませんでした。あと、DATAについてはやはり元ネタ通りの配置が良いのかなと(^^; (debe)

11/13 00:08 @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 ん，それはCLEAR100とやってA$,B$,C$を定義するとスタックの100バイトx3を消費するのであってますか? (hute)

11/13 00:13 @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 理解できました。ありがとうございます。領域が狭い中で同一文字変数を何度も使うとGCが頻繁に起こりますね。なるほど。 (hubi)

11/13 00:03 @Ackieee @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 文字列全体です。ただしREAD-DATAと直接代入分はプログラムアドレスを直接指すので領域を消費しないようです(テクノウより) (higo)

11/13 00:13 @Ackieee @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEAR100→文字列領域100バイト確保、A$,B$,C$定義→変数領域の4バイトずつ(文字数とポインタ)×3確保です。 (hudo)

11/13 18:41 @tiny_yarou @Lindberg1999 @Ackieee @akikawa134 @beautyplanets @gorry5 @SOW74656 データを1行最大71文字で3行に詰め込むと、READの行番号サーチ回数が減る分速くならないかな…今試せないけど。 (danu)

11/13 19:20 @tiny_yarou @Lindberg1999 @Ackieee @akikawa134 @beautyplanets @gorry5 @SOW74656 ああ、ダメそうですか。じゃあなかったことに(^^;)。 (bako)

11/13 13:06 @tiny_yarou @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @SOW74656 最初の頃、RESTOREだけ入れてましたが、取ってもタイム変わらなかったので外しました。直接指定すると変わるかも。 (tapa)

11/13 19:46 ーーーここまで読んだーーー (behi)

11/13 00:03 @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEARで確保されるのは文字列の実体を格納するエリアのバイト数だったはず。（続 (hige)

11/13 00:03 @RetroComPeople @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 ストリングディスクリプタは４バイト×要素数分が単純変数領域に確保される (hiza)

11/13 00:13 @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 CLEARは文字列の実体を保存する領域全体のサイズなので、それでおｋですね。 (huba)

11/13 00:23 @Ackieee @akikawa134 @Lindberg1999 @beautyplanets @KAW6001 @gorry5 @tiny_yarou @SOW74656 ちなみにDM=FRE()として強制的に掃除してやればGCは回避できます。 (hoso)

11/13 12:45 oO( GORRYさんががんばっておられた… (sudo)

11/13 15:15 @gorry5 タイマーのほうがおかしいとかあったりしないかな (heki)

11/13 15:20 (@gorry5) @shinsan68k 60Hzが58Hzというと誤差3%以上ですが、分単位で計測してるタイマーの誤差が3%以上もあったらえらいこっちゃ… (hemi)

11/13 15:21 @gorry5 負荷によってCPUクロックが変わっておかしくなるとか昔あったなぁみたいな。

11/13 15:21 そもそもえらいこっちゃがとうぜんAndroidってね (hego)

11/13 15:24 (@gorry5) @shinsan68k リフレッシュレートはCPUクロックに依存しない（そもそも外部デバイスからの割り込みで成立する）ものなので :D

11/13 15:24 @gorry5 いや、タイマー側の話ね。計測しているのが実機のタイマーかなぁと (hosi)

11/13 15:33 (@gorry5) @shinsan68k タイマーもRTC（のはず）なので、CPUの外側ですわね

11/13 13:05 @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @Lindberg1999 @SOW74656 あらかじめ"RESTORE行番号"を入れておくとちょっと速くなったりして。 (tadu)

11/13 14:38 @Lindberg1999 @Ackieee @KAW6001 @akikawa134 @beautyplanets @gorry5 @SOW74656 READ文は&HFF5C,5Dに書かれているアドレスからDATA文を探していくのでRESTORE行番号で先にセットしておくと早 (nora)

11/13 19:11 @KAW6001 @Lindberg1999 @Ackieee @akikawa134 @beautyplanets @gorry5 @SOW74656 以前試した時は行数を減らしても効果は感じられませんでした。あと、DATAについてはやはり元ネタ通りの配置が良いのかなと(^^; (debe)