僕が最近作ってるアレ関係の話ね。 ほしけん氏作のやつを えいだ氏が改良したやつには キャッシュが付いてたんだよね。 恐らく、以下のような処理を していると解読。 『描画しようとしている文字データが キャッシュに存在しているか判断。 *無ければデータを作り、使う。 データをキャッシュにCOPY、 キャッシュに空きが無ければ 古いものを消して空きを作る。 *在れば、そのデータを使う。』

キャッシュって言っても たぶん一概には言えないと思いますが、 このトピで言うキャッシュは あくまで文字を描画するときに扱う データに対しての話です。

【メリット】 一度描画した文字であり、 キャッシュにデータが残っていれば 高速でデータを読み出せる。 (場合にもよるけど数倍速くなる)

【デメリット】 *メモリを使用 (空きをどれだけ作るのか、にも依るけど 少なければ取るに足らない程度の量) *キャッシュにデータがある場合とない場合で 速度に大きな差が出る→不安定。 *キャッシュに存在するか否かの 条件分岐をする分の処理が掛かる。 (大したことはないだろうけど)

以上のことを想到し、 僕のやつにはキャッシュは 実装しないでおこうと思ってます。 不安定だということを考慮してまで 実装するメリットってありますかね?

一応、ツララ氏か誰かが 「メモリを犠牲にして 全ての文字のデータを先に展開しておく」 系の話を出すかもしれないので 言っておきますと、 「速度的には数秒あれば可能だけど、 メモリが全然足らなくなる」 ってことになります。

キャッシュにデータがあれば処理が早く済む分、何か他にやりたい処理があればそれを盛り込む、とか考えられるけど、そこで他にやりたいことなければ別にキャッシュにしなくても良いかと思います。

メモリって言っても配列を使うんじゃなくて別ファイルとして保存しておいたのをグラフィック画面にロードしたり、グラフィック画面のドットを変数の代わりに使うとか色々あるんじゃないです？ 空きスロットをDATA文だけの外部メモリみたく使うとか。 速さよりも複雑な展開の式を考えなくてもそっくりそのままポンと使える方がメリットかも。

高速化のために使うキャッシュの目的だと、大容量でアクセスが遅いところにあるデータを、小容量でアクセスが早いところに覚えておくのが目的。 プチコンでデータを持てるエリアっていろいろあって、どれが早いか遅いかはあると思うけど、変数が一番早いのはイメージ付くはず。 ほしけんさんのは、やたら長くて多いDATA文を文字列変数に入れて、描画するたびにそのやたら長くて多い文字列から切り出してるので重たいというイメージ。 キャッシュの処理は見てないけど、１文字データの配列に入れてるからアクセスが早くなるというイメージ。 データとして頻繁に出てくるのが決まっていればキャッシュがあれば早いけど、 データとしてランダムならキャッシュがあってもあんまり早くならないイメージ。 ※ひらがなカタカナだけキャッシュしておいて、漢字はストレージからってのでもいいと思いますよ

＞たんじぇさん ストレージとかパソコンベースの話をされても困るんじゃないです？ 処理スピードを自分の使ってるパソコンでの速さで0.0何秒みたいなトンチンカンなこと言っちゃう人みたいですし。

そもそもキャッシュもパソコンベースの話だったり（そっちのほうがトピック内容的に難解）

»ツララs:DATA文だけの外部メモリ 一応、脳内RUNした限りでは そうした方が速そうですね。 ただ、32*32フォントとかだと 数千行に渡る巨大なDATA文が 出来上がりそうだし、 現在作っているものとは 処理が違いすぎているので、、、 とりま現在のやつを完成させてから そっちVerを作りたいと思います。

あーーー　いや、計算上無理ですね。 DATA文は文字列を使わないと 文字数オーバーになっちゃいます。

ということは、結局、現在作ってるやつが 一番良いってことか。(安堵)

＞たんじぇさん キャッシュが一時的な記憶領域ってことならMK2でもシステム変数のMEM$が該当すると思うんですけど どこら辺がパソコンベースの話なんです？ プチコン３号で言うストレージって何に相当するんです？SDカードの保存領域に別ファイルとして保存ってことです？ なら別に難解でも何でもないんじゃないです？ そもそも自分がトンチンカンって思ったのは検証もしてない独断の憶測をさも当然の用に話して 違う意見が出たくらいでうろたえてる感じの人と似てるなーって思ったからだったんですけど。

HBCCみたいに"高速キャッシュに頻繁に使用する文字(平仮名等)を入れて、それ以外の文字を使う際は毎回インポートする。"みたいなことは出来ないのだろうか...。

あっ...。たんじぇさんの意見と被っていました...。

ストレージというプチコンで使われてない単語を出しただけで困る人がいるって考えたり、キャッシュの仕組みが難解って言っているのにストレージが難解って考えるほうがトンチンカンだと思うんですがどうですかねー？ 「早さよりも複雑な展開の式を考えなくても」と書いてあるように、高速化のキャッシュが難解であることが理解されてると思うんですがどうでしょう？ 前に書いたのに注釈をいれると。 高速化のために使うキャッシュの目的だと、大容量でアクセスが遅いところ（ストレージ）にあるデータを、小容量でアクセスが早いところ（キャッシュ）に覚えておくのが目的 アクセスが遅いところにおくのは高速化のためのキャッシュじゃないです これが独断の憶測だと思うならどうぞ「キャッシュ　ストレージ」あたりで検索して調べてください。（スマホ系のは方向性違うで注意）

キャッシュメモリの概念にとらわれすぎなのでは。 キャッシュによる高速化は「大容量で遅い場所のデータの一部を小容量で速い所に置く」ってのをよく聞くけども、それだけじゃない。 暗号化されてたり圧縮されてたり、「データが利用できる形になっていないもの」を「利用できる形で覚えておく」処理もキャッシュという。 これは別に高速のメモリでなくてもいいし、場合によってはキャッシュの容量の方が元のデータよりも大きくなることもある。 が、高速になる。 プチコンのフォントならこっち。 「ヒット」と「ミス」がある伝送路効率化回路がキャッシュ。 当たり前だけど全部展開しておくのはキャッシュとは言わない。

キャッシュ入れたときのデメリットは ・複雑になる ・メモリを食う だけではなく ・ヒット判定の遅延 ・内部保存の遅延 がある。 データ構造によるけど、メモリをけちるとヒット判定がめんどくさかったり、遅かったりする。 プチコンのように配列アクセスも文字列アクセスも遅いと、保存の遅延も馬鹿にならない。 一般にバッファやキャッシュは後から入れて問題ない。 とりあえず無しで作るのはいいんじゃないかね。 作ってからパフォーマンス測定してみればいい。

れいさんの説明のキャッシュについては、展開後のデータが大容量などで全部メモリに入らない（か入るかわからない）ようなもの、身近なところだとMP3ファイルや映像ファイルの再生で使われていたり。 再生するのに必要な分をメモリに展開しておくけど、１小節後とか１分後とか次のチャプターとかを再生するときに、指定された再生位置がメモリにあれば使うし、なければファイルからメモリに展開するし。 モノによっては次に再生する位置が決まってるからキャッシュしておいて、読み込み遅延無く再生してくれるのもあるけど、 映像編集とかリアルタイムに音や映像加工するソフトはいろいろ工夫してるので一概には言えないのも。

５月公開のフォントエディタのコード読んできたけど、フォントデータのインデックス配列と生データ配列で分かれて(どっちも文字列)、インデックスから描画文字検索して、データ配列からビット有効な位置に描画している感じ。 フォントサイズも数も自由に指定できるので、これが大容量になるとキャッシュより先に圧縮と展開（＋キャッシュ）を考えないといけないかもです。（れいさんの行っているプチコンのフォントならこっちって言ってる方法） キャッシュ先は今のインデックスとデータ配列を更新する感じでいけそうかも。 とはいろいろ実装しようとすると完成が遠ざかるので、プチコンならまずは完成してからでいいかも。 完成させてみて、ほんとにキャッシュが必要かとか、他に実は遅いところがあったりかみつかるかも（GFILL引数は演算回数的に一回変数に入れたほうがいいかも？）

ああ、前に公開したやつとは 描画方法まるっきり違ってるんで。 現在と比べれば全然遅いやつなんで。