個人的に配列変数は凄く便利な存在だと思っています これを使えばスプライトを1000個出したり、RPGやそれに近いシステムのゲームを作りやすくなったりすると思います しかし、多くの方が重い重いと言っていて少し不安になりました 一体全体、どれくらい重いのか？ 使うなら要素数はどれくらいがちょうどいいのか？ どなたか詳しく教えて頂ければ幸いです

一言。 3DSではスプライトは511個までです。

＃1個足りなくない?:-p 配列確かに遅いと思うけど、何かプログラム作る前から気にしてもしょうがないと思いますよ。 ちょうど良いかどうかなんて作る前から分からないし、遅いからって配列使わなきゃどうにもできないこともあるだろうし。 何か作ってて遅いなぁと実感してからう～んどうしようかと色々考えた方が幸せだと思います(^o^) ＃まだ起きていない先の心配をしても意味がない ＃とか誰か言ってなかったっけ?

配列で重いことは他の方法でも重かったり、そもそもその配列の使い方が悪かったり、ループ内に必要ない処理が配列処理につかえる時間を圧迫していたり・・・色んな原因・要素が考えられるので基準もあいまいで、一概に速い遅いと言いにくい気がします。 少なくとも、他の処理に比べて配列だけが極端に遅いとは思えないので、鵜呑みにして使うのを不安に思うより、ガンガン使ってみるといいですよ～。それがまた楽しい。

フレームバッファ的にGRPにgloadで独自管理すればという話では？＞1000個 変数=変数より配列[n]=配列[n]の処理が7倍以上遅いらしいです。

もっともこれは配列を要素決め打ちで読み書きする場合なので 回避策としてCOPYやpop/push、ARYOP(有料)を使えば割りと高速です。

配列を作成したらなるたけ配列[n]経由でのアクセスをせず、GLOAD/GSAVE、COPY、POP/PUSH、ARYOP/RINGCOPYを使うといいかと。 つい先日、上画面全域(400*240)の配列をCOPYでシフトさせる処理を行い、GLOADに流し込むというソースを書きましたが、処理落ちせずにスライドに追従してくれているようです。https://miiverse.nintendo.net/posts/AYMHAAADAAADV44HVin-rw

遅い速いは相対的な話であって、絶対的な基準はありません。 で、なぜ配列が遅いと言われるかというと、 「組み込み関数よりも遅いから」 です。 sin(theat) よりも sin_table[itheta] の方が遅い とはいえ、配列を他の方法で代用しようとすると、まず間違いなくそっちの方が遅くなります。 なので、気にせず配列使っていいよ!! だいたい、そんなの気にしてたら、乗算だって除算より遅いんだからねっ!!

スプライト1000個と言ったのはmoh6anさんの言う通り独自管理すれば、という意味です 皆さんありがとうございます 7倍の遅さでは確かに使いづらいですね mo6anさんの投稿拝見しました 背景のスクロールとかできそうですね ゆっくり吸収させていただきます 自分にはPOP/PUSHが一番有用だと思いました 今後はその方法で配列アクセスするようにします

MIKIさん、ありがとうございます 気にせず配列使うようにします 乗算… 出会わない方が良かった知識… 最近では気にせず乗算してますが 最初はn*nをn/(1/n)に変えるべきかでさんざん悩んだ記憶があります

皆さん趣味でプチコンやってるのだろうから、いろんなプログラミングがあると思うのだけれど、 ・バグのないプログラムを書く ・早く完成させる ってのは多くの場合大切な目標になりますよね。 そのためには ・読みやすいコードを書く ・効率を気にしない というのが超重要なポイントになります。 効率を気にするのは、バグのないプログラムを完成させてからでも遅くない。

「組み込み関数より遅い」のもそうではあるんだけど、より一般に 「他の言語・環境での各種ロジックの速度を比較したとき配列アクセスが目だって遅い」のが問題なだけ。 普通はsin(x)より配列10回読み込みの方が圧倒的に速い。 普通はpush1回より配列10回書き込みの方が圧倒的に速い。 普通は画面に一つ点を打つより配列10回書き込みの方が圧倒的に速い。 なので、速度を追求しようとしたときに普通使えていた技が使えない。 普通、配列は圧倒的に速いので、高速化の際によく使うんだけど、それが使えない。 ただそれだけだよ。 配列がないとまともにプログラミングできないので、使うべき。 ただ、「プチコンは普通の環境じゃない」ってのは頭の隅にいれておくのをオススメする。

全くの同意件ですね 「バグがない」 なんていい響きでしょうか 第一にこれ、効率など二の次です 何だか勇気が沸いてきたので、近いうちにゲームを公開できると思います

れいさん 分かりました 極端に遅いわけでもないとは薄々思っていましたが 他の言語だとそんなに速いのですね オドロキです

正直「信じられないくらい極端に遅い」よ。 いろいろ便利な小技が全く使えない。手足をもがれた感じ。 でも、逆に小技使えないので読みやすくなるところもあるし 変態テクニックを考える頭の体操にもなるし 他の環境での配列の偉大さを感じることができるので 悪いことばかりではない （という無理矢理擁護しておく （でもやっぱ違和感ないくらいに速くできるならして欲しい…

＃私の憶測による勝手な理由付け。 ＃適当なこと書きますのでどうか信用なさらずに^^; 一般にゲーム機のCPUというのはパソコンのに比べると遅い。但しゲーム機では画像処理は大事な機能なのでCPUとは別にそこそこ性能の良い画像処理専用のもの(GPUっていうのかな)が積んである。 配列なんかはCPUで扱うから速くないが、画像処理に関係するものは速い。この画像処理に関係するものには、今時のゲーム機では当たり前になっている3次元空間を表現するための、実数計算を扱う機能も含まれていて、なので三角関数とかは速い。 除算が乗算より速いのは、3DSのCPUに使われているARMコア自体に除算機能が備わっていて除算が得意(もしかしたら逆に不得意だったかも^^;)。 とか思っていて、なら遅くてもしょうがないかぁ、と納得することにしています(^o^) ＃にしてもやっぱり配列は遅いか^^;

れいさん その「普通」って、太古の basic か、あるいはコンパイラ言語じゃない?? 最近のインタープリタ言語で確認しましたか? (私自身はインタープリタ使う場合ってそもそも速度とかあまり気にしないから、いちいち速度比較とかしていません) れいさん自身も以前言ってたけど 「配列が遅いんじゃなくて他が速いんだ」 って結構真実なのでは? 特に浮動小数点演算について。 配列の場合、 ・シンボルが配列であること(プチコンはコンパイル時ではなく実行時にシンボルの型チェックしてるから遅い) ・指標の範囲チェック とかやってる間に sin は演算を終わっちゃってるって感じ?

速かろうが遅かろう(重かろう)が、必要な分だけで回せば気にはならないですよ。 配列変数を止めて例えば文字列の配置に変えれば処理は速くなりますがプログラムの解析(狙った場所にある文字を求める)はしんどく感じるかも知れないですね。どうすればいいのか分かってないと出来ないテクニックですので。

> その「普通」って、太古の basic か、あるいはコンパイラ言語じゃない?? 最近のインタープリタ言語で確認しましたか? > (私自身はインタープリタ使う場合ってそもそも速度とかあまり気にしないから、いちいち速度比較とかしていません) 太古BASICでもCでもC++でもFortranでもJavaでも.NetでもPerlでもRubyでもPythonでもここまで遅くはないなぁ。 まぁ変態言語も変態環境も山のようにあるはずなんで「普通」の定義から始めたいというならまたどこか違うところで頼む。 むしろ太古のインタプリタ言語だと配列が遅いことはあった。 もう話者が絶滅してるであろう古代Perl語とか。 配列の速さはそのまま言語の速さに直結するので、最近の言語はみんな意識してるだろ。 つか、プチコンの場合配列がおそいっていうか変数が遅い。 グラフィックや組み込み関数が速すぎる。

> 除算が乗算より速いのは、3DSのCPUに使われているARMコア自体に除算機能が備わっていて除算が得意(もしかしたら逆に不得意だったかも^^;)。 ARMも含め俺の知る限り全てのハードウェア、すべての演算回路において、除算の方が大変。 3DSのARMの浮動小数点周りはどうなってんのか知らないけど。 ARMは整数演算に関して、乗算は1クロック、除算は少なくとも2クロックはかかる。 （普通は5倍程度の時間を見込む。 それでも除算の方が早いので、プチコンの場合ほとんどの時間がBASIC内部処理に使われているのがわかる。

アフロに聞くけど、「信じられないほど遅い」ってどれくらい？ vsync 1より遅いの？ 自分のものさしで「信じられないほど遅い」と形容すんのはどうかね？ 1フレームで最大（だいたい）何回アクセスできるかを示すほうがいいんじゃないの？ おいらバカじゃけぇあんまりわからんけんど、500アクセス程度なら使用に堪えると見たんだけんど

＃深夜のワルノリでワル妄想。 ＃信じちゃダメ。絶対^^; 配列が遅いのは、高度サウンドユニットを売り付けるための戦略。そしてこの高度サウンドユニットの存在により、将来的にも配列が速く改善される見込みは薄いと思われる。 なぜなら配列速くしちゃってユーザー関数でも高度サウンドユニット相当のことが可能になっちゃうと、高度サウンドユニット買ったユーザーから「金返せ～」とかのクレームが沸き起こり、対応が大変になるから。 詰みました。投了:-p ＃ほんとに信じちゃダメだからね^^;

バグが無いのは確かに気持ちいいとは思いますけど そんなにバグを怖がってもしょうがないと思いますよ？ 自分なんかはバグが出たらむしろ原因探すのを脱出ゲームみたいな感じで楽しんでますけど。

> vsync 1より遅いの？ 「各種環境での各種ロジックの速度を比較」と上に書いてある。 垂直同期は人間の目の反応速度から遅くて30Hzはやくて120Hz程度なのでどの環境でも対して変わらんでしょ。 Vsyncのような絶対的な時間の話をいっているのではなく。 「命令間の相対的な速度」を考えて「配列アクセスが信じられないほど遅い」と形容している。 例えばプチコン3号ではsin1回30us、配列読み取り1回45us程度の時間がかかる。つまり配列読み取りはsinの1.5倍。 一方、とあるpythonインタプリタではsinが0.3us、配列が0.1us。配列が1/3の時間。 とあるCコンパイラではこれが1/100以下になる。

この「命令間の速度の比が普通ではない偏り方をしている」というのは良い面も悪い面もあるが、少なくとも注意すべき点。プログラミング初学者、情報科学初学者は特に。 他の言語からアルゴリズムを借りてくる際にも、逆に他の言語へ移行する際にも問題になる。 > 1フレームで最大（だいたい）何回アクセスできるかを示すほうがいいんじゃないの？ 一方で「Vsync1回で何回乗算できるか」というような「絶対的なプチコンの速度」というのは、プチコンが速度の違う3DS/new3DSで出ているようによく変わりうるもので、気にしなくていいというわけではないが、ごく当たり前に変わる部分。 > 自分のものさしで「信じられないほど遅い」と形容すんのはどうかね？ 留意すべきと思った点を指摘するのに、自分の感想と共に述べるのに何も問題ないね。

画素ごとに配列処理して合成してgloadに流し込むというのを配列［w*h］をforで廻してという手法がめたくそ遅くて辛いっす。エアブラシ64*64であっという間に要素4,000オーバー

お勉強になるトピック！ 他の言語とかよくわからないので話を見ているだけでも楽しいですね( ´ u ` ) 配列が遅いというのは完全に同意です。理論的にどれくらい遅いかはわかりませんが、経験則からかなりの実感が…7(･ω･7) 処理が重くなってきたー、っていうときは必ず配列の使い方を見直してる気がします。そして大体配列アクセス抑えると効果があります。 その配列を使う範囲の最初で変数に代入して、以降その変数を使い続ける、っていうのは体感で効果高い気がしてるので、2回アクセスするなら変数に代入するようにしています。 多分SPで配列使ってると1アクセスが何十何百アクセスになるから効果高いのかなー、と。 そしてVAR()とかSPVARは配列より遅かった記憶。配列が遅いから、と代わりに使おうとすると逆に悪くなるかもです。

正直配列が遅いとかそういう事をやっていないので 分かりやすさ、バグの出にくさのほうを重要視してつくりますかね・・。 GPSETは流石にちょっと遅いかなと思ったけど あとはUSEが遅すぎ・・。

プチコン速度七不思議(まだ3つ) 変数>定数 除算>乗算 関数>配列 ???>??? ???>??? ???>??? ???>??? なんだこれは...たまげたなぁ...。

たくさんのコメントやアドバイス、感謝の一言に尽きます れいさん いろいろと親切に説明してくださり本当にありがとうございます 知りたかったことが知れました 忠告は有り難く受け止めます ツララさん、るかか3DSLLさん プログラミングはバグとの闘い、バグとの闘いとは自分との闘いだと考えています その闘いの日々の結晶が完成作品なのだと スーさん 配列が遅いから代わりにSPVAR←いつも使ってました 遅いやり方だったんですね 私は間違った認識をしていたようです

みけらんジェロさん 今回、配列について質問したのは、それを使ってどこまでの処理ができるかを考えるためであり「これだけ必要」という指標があるわけではないです 最初に言った独自のスプライト1000個というのも、10000までいけるならそうします しかしそれは、ARYOPでも使わない限り厳しいですよね SilverBlueさん 七不思議ならぬ三不思議 笑わされました

れいさん 定義とかじゃなくて、自分で調べるよりれいさんに聞いたほうが手っ取り早いかなと思って。ポリポリ・・ スーさん >VAR()とか 文字列の演算は基本的に遅いですよ。 たとえ固定文字列であっても、var() は実行時に文字列からシンボルテーブルを検索するので、コンパイル時に決定される通常の変数に比べとても不利。 >SPVAR 配列代わりに spvar ?? spvar(sp, i) は式を二つ(spとi)と 関数呼び出し(spvar)一つですね。 v[i] は式が一つ(i)と 配列評価(v)一つなので、配列が遅いといえど式一つ分よりは速いってことでしょうね。 式評価にかかるおよその時間は以前コメントしました。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0fPso64pw 当時は中間コードを生成してるのかと思ってましたが、実際は

続き: 実際は式の構文木を作り、右回りの評価してるみたいですね。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0gJu05MqQ 文字列が遅いってのはいちいち全体の複製処理が発生するから。 a$=a$+b$ の場合、a$の値は保持したまま、 a$+b$ という新しい文字列の入れ物をどこかから確保してa$とb$の内容をそこに複製し(※) 改めてそれを a$ に設定する。 a$ の古い値はとりあえず空き家となり、いつかメモリが足りなくなると、回収されて再利用されることになります。 inc a$,b$ の場合 a$ の値の後ろがたまたま空いていたら、そこに b$ を複製します。 先の※(確保・複製)の処理がない分速いのです。 もしたまたま空いてなかったら結局※の処理が発生しますが。

あ、なんか見てきたようなこと書いてるけどあくまで推測です。 でも大きく間違ってはいないと思います。

ステップのお話は覚えてました！自分で計算しろと言われても出来ませんけど、一応概念だけは(・u・) VAR()やSPVARは、昔「配列が遅い」という情報だけが最初に流れたときに、じゃあ別のにした方が良いのかなー、と使った例でした。SPVARは配列とSPを組み合わせて使っているときに代わりにしたのです。 今ならVAR()は明らかに遅そうな気がします。成長分。SPVARは計ってみたところ二次元配列よりもちょっと遅かったので、関数呼び出しよりは配列評価の方がちょっと速いのかもしれません。 右回り評価は、SHIFTが右から、って文脈で見たことがある気がしましたけど普段は全く意識してなかったですー。罠っぽいので頭に入れておこう。。 わかりやすくて詳細な説明いつもありがとうございます！(*´∨`*)ﾉ

前にも別のトピックで報告させて頂いたのですが、いい機会なので再度投稿させてください。 ちょっとした配列関連のサンプルを用意させて頂きました。 特に気にしなければ０から５まで、処理時間的には大差ない様に思えます。

結果はこんな感じです。 （文字列、数値とも操作内容によって処理時間は大きく変わるのであくまで参考値で） 前に報告させて頂いた時に「文字列配列は何処かでGCされているのであろう」という話を頂いたんですが、実際どの様な挙動をしているかは不明です。 なお、文字列変数で同様の処理をした場合、代入自体は比較的早く文字列操作をすると同じ結果になる様です。 ここいらはMIKIさんが言われている事に繋がるかと。 他の言語と比べて速度が...という話ではないのですが、話のネタになれば幸い。

Picsで高速化を試していた時に、プチコンの処理速度は、処理の内容を問わず、インタプリタであるゆえのオーバーヘッドに依存すると考えました。GPSETやGSPOITなどの命令はVRAMアクセスになるため、ハードウェア的なウエイトが発生してそうですが、2次元配列に置き換えても速度差はほとんどなかった、と、当時テストの上で認識しています。 ARYOPも処理するデータ量を考えれば爆速なのですが、呼び出しのオーバーヘッドが大きいので複数回呼び出すと途端に重くなります。なるべく一度の呼び出しで多くの領域を処理した方が高速化が望めます。GCOPYなどのVRAMアクセス系命令は、若干違っていてオーバーヘッドに加え、一度に処理する量もそれなりに影響するみたいです（きちんとした検証はしてないです）。

FOR文も若干ですが遅いので、到達値をあらかじめ計算して変数に代入しておいたり、REPEATに置き換えた方が高速になりました。このあたり、除算と乗算などは、中のネイティブコードによる誤差かもしれません。 それよりも気になるのは、上級者が「配列は遅い」と書くと、初心者の方がその意味をうまく理解できず、混乱してしまう場合でしょうか。個人的には、旧3DSでも配列を使いつつ、数百枚のスプライトをフルフレームで動かせるので、よほど特殊な事をしない限り、あまり気にしなくてもいいと思ってます＾＾ あ、便乗してご報告すると、BIGのBGMPLAYやBEEPが、3号と比べとてつもなく遅いです…多分これは、サウンドハードへの手続き依存なんでしょうね…。今作ってる物が、BIGよりも旧3DSの方が速くなる、と言う逆転現象発生で、仕様を変更せざるをえなくなりました＾＾；（※普通の使い方では影響ないと思います）

混乱したとしても、このトピックのように皆で説明すればいいだけの話なのでそれほど問題ではないでしょ。 わざと混乱させようとしているならともかく。 それよりも「これは初心者を混乱させるかも」と思って自粛する雰囲気になるほうが問題だとおもうなぁ。 多少スキルに違いがあっても、教育者や披教育者ではなく、同じゲームであそぶ仲間なので、スキルや前提知識の違う会話をしていてもいいし、むしろそれがいい。

そうですよね。初心者にとって難しい内容だとしても、示されてないよりは示した方がマシ、というより示されてないとダメだと思います。行き詰まっても情報なくて困るのは初心者の方が多い(熟練者は自分で色々試して解決できたり)と思うので、これちょっと初心者には難しいから省略して伝えよう、とかは要らぬ気遣いだと思います。そして初心者はいつまでも初心者じゃない。意外とすぐ初心者じゃなくなるもんです。世間に溢れる「初心者向け～」なんかは初心者というより初見で終わりの情報で、もっと詳しい情報がそれに埋もれて中々見つからないのがイライラする。そもそも初心者向けってなんだ?面倒くさいこと省くための言い訳か?なら初心者向けって言葉使うべきじゃない。万人向けを目指すべきだ～。 って突っ走り過ぎました(^^ゞ そういえば、配列って実数型より整数型の方が速いみたいですね(今更感)。

初心者が混乱するから、議論をするな、みたいな乱暴に聞こえてしまったのなら、すみません＾＾； 初心者はそうでなくても配列を理解しにくいようですし、そのまま使わなくなってしまっては大変だと言う意味での発言でした。遅いと書く場合は、同時にどれくらい遅いのかや、それを回避する方法も掲示できれば良いんでしょうけどね… 以前、確かBIGのスレで初心者の方が、配列は遅いので使わない方が良い？と質問しているのを見ていましたし、ループして処理すべき所を、配列を使わず、全部通常変数とIF文で作ってしまった方も身近で見ていましたので＾＾； キルル2さんの質問にある、配列の重さについてですが、具体的な事を示さないままもあれなので、雑ですが実際に計測してみました。手元にあったBIGで1千万回ループした結果（単位は秒）ですので、3DSでは傾向が多少異なるかもしれません。

FOR 2.18 /REPEAT 2.03 A=0 0.9 A=A+I 1.05 /INC A,I 1.81 A=A*I 1.20 /A=A/I 1.18 B[0]=0 2.55 /B[I]=0 3.05 A=B[I] 3.50 /A=SIN(I) 2.93 /A=SIN(I)*8 3.95 GPSET 0,0,0 3.76 /C[0,0]=0 3.11 /C[X,Y]=0 4.01 SPOFS 0,X,Y 5.33 /SPOFS 0,B[I],B[I] 10.21 SPOFS 0 OUT X,Y:SPOFS 0,X,Y 9.45 INC、乗算、GPSETが遅いなど、だいたい噂通りの結果が出ているとは思います。意外だったのはスプライトが思ったよりも遅かった事… この結果だと微妙な差の所もあるので、明確にこれは避けた方がと言うのは言いにくく、処理内容によって、最適解は違ってきそうですね。

旧3DSでも実行してみました。 FOR 23 /REPEAT 18.83 A=0 8.16 A=A+I 9.5 /INC A,I 15 A=A*I 12.33 /A=A/I 9.5 B[0]=0 30.5 /B[I]=0 32.83 A=B[I] 40 /A=SIN(I) 37.66 /A=SIN(I)*8 54.16 GPSET 0,0,0 62.83 /C[0,0]=0 36.16 /C[X,Y]=0 41.83 SPOFS 0,X,Y 68.5 /SPOFS 0,B[I],B[I] 123.5 SPOFS 0 OUT X,Y:SPOFS 0,X,Y 119.5 追加テスト BEEP 0 5131:BIG 810:3号 GCOPY 4,0,0,15,15,X,Y,FALSE 22.63:B 485:3 GCOPY ～0,0,127,127～ 692:B 21637:3

配列の整数型が実数型より速いと言ったものの、それはBIGでのことだったので、3号(旧3DS)でも確認してみたら、ほとんど変わらないみたい(試したケースではむしろ実数型の方が僅かに速かった)。 ケースにも依るだろうし、一概に速い遅い言うのは難しいかもしれませんね。

MIKIさん spvarのことは二次元配列と同じようなものとしか捉えていませんでした いろいろと違うのですね 文字列が遅いという話、勉強になります スーさん 自分も「配列が遅い」という情報を見て別の方法を使ってきた口です 認識が改まりました ishさん テストありがとうございます！参考にしますね！ すうさん 処理の内容は問わない、という考え方は当たっているような気がします 私は3号しか持っていないので分かりにくいのですが、BIG独特の苦労もあるようですね 私がプチコンを始めたころは、配列が何なのかわかっていませんでした (通常変数とIF文で、全部作ってしまっていた) 具体的な数字まで出していただいてとてもありがたいです

れいさん 人とやりとりができるというのは、それだけで助けになったり技術の向上に繋がったりしますね スキルや知識に差ある方が、その効果は大きいということでしょうか 確かに、自粛する雰囲気は良くないと思います しんいちさん 私にも情報がなくて困った経験はあります 自分で試した方が早いというのが現実ですよね そんなときに「配列は遅い」なんて見かけて、ろくに試しもせずに信じた自分を呪いたいです 欲張りかもしれませんが万人向けは欲しいところですね 速度はケースによって変わるというのはよく分かりました 確かに、あれが遅いこれが遅いなんて、いつまでも言ってたところで、ゲームは完成しませんね

私のあの暴走はここの投稿者の誰かに向けてということでは全くなくて、日頃度々現れるプチコンの謎仕様に悩まされ溜まったストレスが漏れ出てしまったものでした。反省m__m。 バグ改修や機能改善はもちろん大事だと思うけど、SmileBoomにはもうちょっとドキュメントの充実、仕様開示にも力を入れて欲しいなぁと思う今日この頃。不明なことも試せば大体分かるっちゃ分かるんだけど、その頻度が多すぎていつの間にか試すことだけに終始しちゃうことが度々orz ＃おっと脱線。 ＃そろそろトピ閉めたかったかな。ごめんね。