どうしたらいいのでしょうか。 プログラム中のコメントや空白、改行等を消し去って、容量を減らすプログラムなのですが、 約10000行辺りのプログラムは、約2時間かかってしまいました。 そのときは59FPSだったのですが、ここまで時間がかかるものかと疑問です。 どなたか、協力お願いします。 公開キー【VKEEE3HJ】

高速化のための高速化か、、、

落として手を入れてみました。 方針は「とにかくPRINTしない」です。 上画面のコード表示は切りました。これで14%速くなりました。 あと下画面の進行を1行終わる度に表示するのも重いだろうと考えて20行に1回にしたところ25%速くなりましたなりました。 結果40%のスピードアップです。 計測は処理前と処理後のMAINCNTの差で見ました。

3号は演算は最適化するけど表示は相変わらずネックなんだよね。

よ、40%も...!!やっぱり表示って重いんですねー。 いやぁ、上画面のはかっこいいかなーって。 ありがとうございます!!　それじゃあ後は色々頑張って軽くしていこうと思います!

RPGGETやPRGSETはなるべく使わないようにして変数内で処理した方が早いんじゃないかな？って思ったりもします。ただ推測なので試したわけじゃないんで効果がなかったらすいませんが…。 表示もそうですが、処理のボトルネック（どこが遅いか）を検証してから最適化した方が効率的に早くすることが出来ると思います。

高速化してみた。だいたい10000行で1分@new3DS≒4分@old3DSが限界かな。 問題はPRGEDIT。 PRGEDITはカレント行を決定するけど、そのためには頭からデータを読んで行番号を数えないといけない。 行番号が小さいうちはすぐ終わるけど、後ろのほうになるとたくさん探さないとわからなくなる。 それを何回もやるから遅い。 もう少し正確に言うと、 行番号をnの行を探すのに、改行記号をn個探さないといけないからだいたい「nに比例した時間」がかかる。 1行目を処理して、2行目を処理して、…ってn行目まで処理すると、合計だからn*(n-1)/2、つまりn^2に比例した時間がかかる。 nが10なら100くらいだけど、nが10000なら100000000の時間がかかるわけ。 そこを直さないといけない。

画面も少し重い。特にスクロールね。 でも、スクロールは改行のたびに起きるだけだから、表示行数が多くてもそれに比例した時間しかかからない。 上の計算と同じように言うなら、nに比例した時間しかかからない。 10行表示するのにかかる時間と、10000行表示するのにかかる時間は1000倍くらいしか変わらない。 10行処理するのにかかるPRGEDITの合計時間と、10000行処理するのにかかるPRGEDITの合計時間は1000000倍違う。 今のままだと処理する行数が多いとどんどん処理に時間がかかるようになるわけ。 結果、10000行処理するとき、画面表示にかかる時間は全体の1%もない。 なので画面表示を省略しても速度はあまり変わらない。

処理行数をnとしたとき、 処理時間がn^2に比例しちゃうのはしょうがないケースもあるんだけど、 このプログラムならうまくやれば回避できる。 問題はPRGEDITなので、これを使わなければいい。 つまり、LOADで文字列変数に読み込む。で、頭から一文字ずつ処理する。 改行文字（CHR$(10)）が混ざるので、これの処理を追加する これだけ。 いままではPRGEDIT+PRGGETで1行ずつ読んで、それを1文字ずつ処理していた。 1行ずつ読むのは他のスロットを読むのに1行ずつしか読めないからだけど、 あとで1文字ずつ処理するならわざわざ1行ずつ処理する必要ない。 これで、処理行数nに比例した処理時間のプログラム、 「アルゴリズムのオーダーとしては最速」なプログラムになる。

PRGGETの方にてを入れるべきでしたか…。 あと私は1500行のコードで試してたので検証が足りませんでしたね。 さすがれいさんです。

PRGEDITは欠陥だな。 常に最初から数えてるので、行数多いとひどく重くなる。 プログラムを書き出したいだけでも、10万行とか超えると大変。 ある程度コード量が増えたら、カレント行を常に1行目にして、PRGINSで挿入したほうが早い。理不尽。 せめてPRGEDITで「次の行」と「前の行」に移動できれば違うんだが。

そのアイデアぱくらせていただきます

皆さん、指摘ありがとうございます！！ とりあえずPRG関係消して、TXTで読み込めるようにします！！