コメント行による速度の影響

No.10384

楽になりたい さん　24/05/29 02:19　[ コメントを投稿する ]

マクロ中に残されたコメント行による処理速度低下はどの程度ありますか？
Haswellでも体感できるレベルにもなり得ますか？

有志の皆さんのマクロは欲しいマクロじゃない。と早々に見切りをつけ自作しています。
最初は20行程度だったマクロも、あれも自動化、これも自動化、そっちも自動化。
と巨大化していきますが、このブロックはこの処理、こっちはこの処理。と言ったコメントは残してます。
その程度ならいいのですが、一度バグってデバッグに梃子摺ると場所の特定用のmessage分を大量に追加して、デバッグ終了してもまたバグるだろうという恐怖心からコメントアウトして残しています。
つまり実質的なコードとコメント分どっちが多い？状態になっています。

C言語などのコンパイラ言語なら全く気にする必要はないと思うのですが、秀丸はどうなのでしょうか？
インタプリンタだとループの中にあったりすると顕著に影響が出そうな気がするのですが。
とふと疑問になったので質問させて頂きました。

[ △ ]

RE:10384 コメント行による速度の影響

No.10385

でるもんたいいじま さん　24/05/29 03:46　[ コメントを投稿する ]

秀丸愛用者の「でるもんた・いいじま」と申します。

> マクロ中に残されたコメント行による処理速度低下はどの程度ありますか？
> Haswellでも体感できるレベルにもなり得ますか？

ほとんど無視できるレベルだと思います。

秀丸マクロの場合、実行時に毎回ソースコードを解析しているわけではなく、まず起動時にファイル全体を中間コードに変換し、それが無事成功してから実際の処理に移る、という仕組みになっています。

たとえば、下記のようなマクロを実行してみると、1行目の message 文が実行されるよりも前に2行目の文法エラーが検出され、そのまま終了してしまいます。中間コードに変換する時点で既にアウト、というわけです。

message "aaa";
message "bbb" // わざとセミコロンを抜いてみる
endmacro;

また、最近のバージョンには「自動起動マクロ」という機能がありますが、そちらの設定画面には「キャッシュファイル」なる文言があります。この「キャッシュファイル」の中身はたぶん、中間コードのメモリダンプそのものだと思います。

[ △ ]

RE:10384 コメント行による速度の影響

No.10386

western さん　24/05/29 10:22　[ コメントを投稿する ]

推測するな計測しろ！の鉄則に則って調査してみました

//https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter
loaddll @"QueryPerformanceCounter.DLL"; // 自作DLL

#beginTick = dllfunc("QueryPerformanceCounter"); // 1マイクロ秒精度のタイマ値を取得
execmacro $macropath; // マクロを呼ぶ (マクロの内容はコメント分 + 最後に endmacro;)
#endTick = dllfunc("QueryPerformanceCounter"); // #endTick - #beginTick の値が経過時間 (間に何もなければ 7マイクロ秒くらい)

// Ryzen 3600X (3.8GHz) 環境にて秀丸エディタ32bit版 v9.35b6 でベンチマーク
// 実際の検証は、Windowsのファイルアクセス状態や他の要因の排除、複数回の実行を平均化するなどして統計データとした

・毎回ファイルが読み込まれ、毎回コードが解析されている
　　１回の実行は 0.3 ミリ秒になる (コメントなし endmacro; のみ)

・コメント文を読み飛ばす早さは 1MB の時に 14ミリ秒 *余分に*かかった (1,047,576バイトのコメント + endmacro;)
　　・コメント部分が 512KB の時は 7.2ミリ秒
　　・コメント部分が 128KB の時は 2.1ミリ秒
　　・コメント部分が 32KB の時は 0.5ミリ秒
　　・コメントの量にほぼ比例
　　・/* ブロックコメント */ と // 行コメントに差はない

・xxx.mac.cache という拡張子であれば、キャッシュがあればコード解析は行われない
　　１回の実行が 0.4 ミリ秒になる (コメントが省かれた小さな .cache ファイルになっている)
　　マニュアルにある通り、小さいマクロの場合は .mac.cache の方が 0.1 ミリ秒程度くらい時間がかかる
　　　　損益分岐点(キャッシュ使わず直接実行した方が早いマクロサイズ)は 2.5KB だった
　　　　コードが100行を超えるようなマクロはキャッシュの仕組みを使った方が良さそう

・128KB (131,072バイト) のコード解析時間 (冒頭の endmacro; で終わる雑多なマクロをコメント除去して連結したファイル)
　　コメント無し最小ファイルと比べて 2.7ms の追加の解析時間が発生 (同じサイズの全てコメントのマクロの場合から 0.6ミリ秒の増加)
　　マクロ指定を xxx.mac.cache とした場合 76KB の解析済みファイルが作成され、キャッシュを使う場合のマクロの実行時間は 0.4 ミリ秒

> Haswellでも体感できるレベルにもなり得ますか？

１メガバイトのコメントが余分に含まれているマクロをキャッシュを使わずに実行した場合、
画面のリフレッシュレートを 60fps とするのであれば１フレーム(16.6ms)の描画の遅延が起こり得て、
それを認識できるゲーマーであれば気付けるかもしれないレベルというテスト結果となりました

※積極的にマクロのキャッシュ機能を使いましょう。それだけで杞憂は解消します

[ △ ]

RE:10386 コメント行による速度の影響

No.10387

でるもんたいいじま さん　24/05/29 11:37　[ コメントを投稿する ]

でるもんた・いいじまです。

> 推測するな計測しろ！の鉄則に則って調査してみました

貴重なデータ、ありがとうございます。
それに加えて、私から1点だけ補足します。

☆　☆　☆

> インタプリンタだとループの中にあったりすると
> 顕著に影響が出そうな気がするのですが。

この点については、先述のように秀丸マクロは中間コード方式なので、「単一ファイル完結」という条件が満たされている限り、
・ループ内でもループ外でも、コメントの文面が同一なら影響は同一
・すなわち、どれだけ反復回数を増やしても、それによってタイムロスが増えることはない
という結果になるはずです。

＃westernさんのDLL（バイナリまたはソース）がもしどこかに
＃公開されていれば、それを使って私のほうでも検証できるのですが、
＃同機能のDLLをスクラッチから自力で書くのは現状、荷が重いです。
＃（当方DLL作成未経験、しかも開発環境がVCではなくMinGWです。）

逆に「単一ファイル完結ではない」場合、すなわちループの中でexecmacroを繰り返し実行する場合についてはwesternさんの実験ですでに結論が出ていますので、この場合はキャッシュを使うなり、子マクロの文面を親マクロの中に埋め込んでしまうなり（すなわちインライン展開）、そういった方法が必要になるかと思います。

[ △ ]

RE:10387 コメント行による速度の影響

No.10388

western さん　24/05/29 11:47　[ コメントを投稿する ]

っ QueryPerformanceCounterL.c

#include <windows.h>

// gcc.exe -shared -o QueryPerformanceCounterL32.DLL QueryPerformanceCounterL.c
// https://learn.microsoft.com/ja-jp/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

__declspec(dllexport) INT_PTR QueryPerformanceCounterL() {
BOOL ret1;

LARGE_INTEGER liFreq;
ret1 = QueryPerformanceFrequency(&liFreq);
if (ret1 != TRUE)
return 0;

LARGE_INTEGER liTime;
ret1 = QueryPerformanceCounter(&liTime);
if (ret1 != TRUE)
return 0;

INT_PTR nReturn = (INT_PTR)liTime.u.LowPart;
return nReturn;
}

[ △ ]

RE:10388 コメント行による速度の影響

No.10389

でるもんたいいじま さん　24/05/29 11:58　[ コメントを投稿する ]

> // gcc.exe -shared -o QueryPerformanceCounterL32.DLL QueryPerformanceCounterL.c

ありがとうございます。
これをベースにして、いろいろ試してみようと思います。

[ △ ]

RE:10389 コメント行による速度の影響

No.10390

楽になりたい さん　24/05/29 23:15　[ コメントを投稿する ]

多数の回答ありがとうございます。

そういえば文法エラーで何度もダメ出し喰らってました。
中間コードに変換して成功してできたキャッシュにはコメント分が含まれていない。よって影響は気にしなくてよい。という理解でよろしいですか？

キャッシュファイル！ありがとうございます。
よく判らないので取り敢えず一番上と一番下だけチェックを入れました。

見切りの良さからサブルーチンを外に出してexecmacroで呼び出すことはコードの再利用（使い回し）などの点で楽なので、積極的に使ってます。
でもループの中で使う事態にはまだなってないと思われます。

replace系の命令が大半を占めるので、親マクロでdisabledrawしてreplaceallfast連発してenabledrawで復帰という工夫はしていますが。

replace系の命令だけでは済まない、URL中の文字か否かの判定とか、括弧の中か否か（ネスト含む）の判定は否が応でもループ処理にならざるを得ないのでトライアンドエラーにならざるを得ない。然もバグが発生しやすい。

ので質問させて頂いた次第です。
宜しくお願いします。

インライン展開は未体験ゾーン。
Win32 API を呼び出す日は来ないのかもしれない。。。
けどガンバ！

[ △ ]

RE:10390 コメント行による速度の影響

No.10391

秀丸担当 さん　24/05/30 09:35　[ コメントを投稿する ]

コメントの速度の影響について、実行する前に中間コードへのコンパイルあります。
いったんコンパイルがあってからの実行中は、ループの中にコメントがあっても除去されている状態です。
なので、ループ内だからという理由でコメントを外に出したりしなくても大丈夫です。

普通の場合はコンパイルが走るので、ループの中や外に関わらず、大量にある場合は毎回の実行時に影響があることになります。
それが気にる場合は、検証などされている通り、execmacroで.mac.cacheの指定でキャッシュを使う方法があります。
他には、何度もexecmacroをループして呼び出す場合、setcompatiblemodeの0x04000000の指定で、.macのまま効率化させる方法があります。

[ △ ]

RE:10391 コメント行による速度の影響

No.10398

楽になりたい さん　24/05/31 01:01　[ コメントを投稿する ]

う～ん。。。裏技というかチート技というか奥義が色々あって頭が付いていけない。

確認したところコンパイルされた状態のマクロがまだない状態です。
FAQで確認したところその状態でもsetcompatiblemodeでループ中のexecmacroを高速化できる。
という理解で合っていますか？

でもマクロの実行が終わるとコンパイル内容が消滅するので次回またコンパイル動作が入ることになりますよね？

ならコンパイルした情報をファイルに保存してそれをexecmacroで呼び出す方が高速化できる。のではないですか？コンパイル動作が入らないのだから。
飽く迄理論上で体感できるレベルではないだろうけど。

色々とご指導ありがとうございます。
中間コードへのコンパイルをせずに使っていることに気付けて助かっています。
今後も宜しくお願いします。

[ △ ]

RE:10398 コメント行による速度の影響

No.10400

秀丸担当 さん　24/05/31 11:02　[ コメントを投稿する ]

キャッシュ関係は、裏技とかチート技のようなものだと思います。
都度コンパイルが基本で、ほとんどの場合は気にしなくていいと思います。
それでもなお気になるという場合は、やっぱり難解になってしまいますが、その技を使ったりするといいと思います。

[ △ ]

RE:10398 コメント行による速度の影響

No.10401

秀丸担当 さん　24/05/31 11:07　[ コメントを投稿する ]

setcompatiblemodeのほうは、最初はどうしてもコンパイルします。
ループで同じexecmacroを何度も呼ぶような場合、再利用することになります。

キャッシュファイルについては、マクロヘルプのexecmacroの一番下のところに説明があって、拡張子を.mac.cacheにするとファイルとして残して再利用したりしなかったりします。

[ △ ]

RE:10401 コメント行による速度の影響

No.10402

western さん　24/05/31 12:39　[ コメントを投稿する ]

>キャッシュファイルについては、マクロヘルプのexecmacroの一番下のところに説明があって、拡張子を.mac.cacheにするとファイルとして残して再利用したりしなかったりします。

自動起動カテゴリにあるチェックボックスとは別の話として
マクロ登録のダイアログのファイル名の拡張子で .mac.cache を指定するなどして
キャッシュの機能を意図的に利用させる設定は用意されないのでしょうか？

コメント量による影響が心に引っかかり、その副作用で貴重な可読性を杞憂により低くしてしまうなど気持ちの問題として

もっと言えば、マクロの再読み込みすら無くすオプションが欲しいという気持ちもあります（気持ちの問題）
（同名の .mac.cache の複数回呼び出しに限りタイムスタンプの確認もされないというのは確認済み）

それが原因で無駄に凝った難解な作り方や過度にマクロ使わない方法を模索したりと、杞憂が本末転倒な事態を起こしてます（笑

[ △ ]

RE:10402 コメント行による速度の影響

No.10403

秀丸担当 さん　24/05/31 16:36　[ コメントを投稿する ]

マクロ登録の時点では、自動起動マクロはキャッシュを作るように指定できますが、それ以外は今のところ無いです。
登録欄に.mac.cacheと書くのはなにかすっきりしない気がします。
個別指定は現状で小さい起動用.macと、execmacroでできるので、やるとしたら、自動起動マクロの設定にように、全部が自動にする指定があったらいいと思います。
そうなると、個別にしたいもの以外の、ほとんどはファイルがたくさん増えてしまうのと、オーバーヘッドが増えるだけになると思いますが、任意で気持ちだけの問題ならそれもありかもしれません。

[ △ ]

RE:10403 コメント行による速度の影響

No.10404

楽になりたい さん　24/06/01 00:31　[ コメントを投稿する ]

全てのマクロをキャッシュ化できるという解釈でいたのですが、
https://hide.maruo.co.jp/software/hidemaru8/macro.html
には『自動起動マクロに設定されているマクロは、キャッシュファイルを作成して実行を高速化させることができます。』という記述があります。

自動起動マクロに関するチェックを全部入れてみましたが、まだ一つもキャッシュ化されていません。
自動起動マクロに指定したマクロが一つも無いからだと思うのです。
現段階では必要性を感じていないので当然です。
自動起動マクロに設定していないマクロをキャッシュ化する方法はありますか？

・［マクロ］－［マクロ実行］で指定されたマクロは.macを実行する。この時表示されるのは.macファイルだけとする。
取り敢えずこれで行こう！という段階になったら
・［マクロ］－［キャッシュファイルを作成する］で指定された.macからキャッシュを作成保存する。
という流れにしていただけると初心者には使いやすくなるような気がします。
複数纏めて処理できると助かります。

裏側（秀丸）は
・［マクロ］－［マクロ実行］で指定された.macはキャッシュファイルがあればそれを、無ければ.macを実行する。
・マクロ登録されたマクロも同様とする。
・execmacroで.macを指定された場合も同様とする。
として頂けると尚助かります。

そうすればキャッシュの有無に関係なく表面上は.macで統一できます。
マクロを作る方としても有無を気にしなくてよいので助かります。
エラーを内包するマクロのキャッシュは作成（存在）しないので秀丸サイドの負荷も大きくはならないのではないかと思います。

また、どっちを実行したのかを記録したログファイルを都度作成して頂けると助かります。
秀丸が指定されたマクロはキャッシュを、execmacroで呼び出されたそれは.macを実行した。ということも有り得るのでファイルのフルネームを羅列しただけのファイルを都度作成すれば、キャッシュ作成し忘れを見つける手助けなどになると思います。
都度作成なので秀丸が指定されたマクロ名を流用したログファイルを実行する度に上書きして構いません。
個人的にはマクロフォルダを汚したくないので、%TEMP%の下にHidemaruなどというフォルダーを作成してそこに作成して頂けると助かります。

勿論タイムスタンプなどによる現行の依存関係チェックは変える必要はないと思います。

> ほとんどはファイルがたくさん増えてしまう

マクロの数が無数に増えるのを是とするか否かはユーザー側の問題で秀丸開発サイドの問題ではないと思います。
ある程度まとまった処理をするマクロを外部マクロとして外に出しexecmancroで呼び出すか。巨大になって見通しが悪くなりデバッグが困難になるのを受け入れるのか。という問題でしかないと思います。
現在は文章を成形するマクロとラジオを録音したメディアファイルのタグファイルを作成加工するマクロの2つを作っています。
前者は親マクロが2つだけで収まっています。正確には2種類あるのでその違いを外部マクロを呼び出すか否かで2つに落ち着いています。
ただし後者は公開情報のフォーマットが放送局でまちまちなので専用にならざるを得ません。つまり放送局の数だけ作っています。

> オーバーヘッドが増える

すいません。どんなオーバーヘッドが増えるのでしょうか？
余程大きなものでもない限りストレージやOSのキャッシュに収まってしまうのではないかと思うのですが。

長くなりましたが、宜しくお願いします。

[ △ ]

RE:10403 コメント行による速度の影響

No.10405

こみやんま さん　24/06/01 09:26　[ コメントを投稿する ]

>そうなると、個別にしたいもの以外の、ほとんどはファイルがたくさん増えてしまうのと、オーバーヘッドが増えるだけになると思いますが、任意で気持ちだけの問題ならそれもありかもしれません。

ぶっちゃけ効果が薄いワリに「ファイルがワラワラ」出来るだけなので
(速度が遅い原因の99%は「マクロの作りの問題」であって、マクロキャッシュの有無ではない)
お気持ちで欲しいなら、マクロの「同一フォルダ」にファイル展開ではなく、「__maccache__」
みたいなサブフォルダ作ってそこにキャッシュファイル押し込めた方がよいかと思いますね。

人気言語も中間コードは100％作成していますが、キャッシュとして出力するオプションを使った場合でも、元ファイルと同一フォルダに出力する、なんて所作するものはほとんどないんじゃないでしょうか。

ユーザーが管理するファイルと、インタプリタの都合で出来た中間コードが
一緒のフォルダにあるという設計は「よろしからず」という印象です。

[ △ ]

RE:10405 コメント行による速度の影響

No.10406

western さん　24/06/01 11:15　[ コメントを投稿する ]

言語や処理の思想にもよりますが

python は .pyc が .py と同じフォルダに並びますし
C言語も .o が .c と同じところに生成されます (設定により obj フォルダだったりもしますが)
node_modules フォルダのように依存関係で１万を超えるファイルがプロジェクト毎に作られるという状況もザラになりました

マクロはこういう環境や処理に近いという考え方も出来れば

あくまで一時的(テンポラリ)なものであれば最小限でよく、後始末の仕組みも含め
%TEMP% 以下で見えなくするのが優しいという思想と考え方もあります (トラブル巻き込まれなければ)

自分は高々数十数百の *同名* のファイルが並ぶだけであれ
ユーザビリティとしてメリットが大きくトラブル要因にはならない
煩わしい要素にはストレスは大きくないという見方をするタイプです
(コメントの話も含め実作業の効率化の方が優先度高)

そういったファイルが出来ても今風の vscode にしても git にしても無視させる仕組みが
標準の機能として目立つように備わって勝手に対応してくれます

秀丸でも設定次第ですが、バックアップとかテンポラリとか
作業の安心感から大量に作られることもメリットと考える人もいますし
その動作設定もこだわりで細かく指定できるのが秀丸エディタのアピールポイントでもあるとも思います

オーバーヘッドも人によって尺度の桁とこだわりが違うのが興味深く
思想を語ると長くなりますね。他者のトラブル回避や効率の考え方の新しい発見にもなります

[ △ ]

RE:10406 コメント行による速度の影響

No.10407

こみやんま さん　24/06/01 12:15　[ コメントを投稿する ]

>言語や処理の思想にもよりますが

>python は .pyc が .py と同じフォルダに並びますし
>C言語も .o が .c と同じところに生成されます (設定により obj フォルダだったりもしますが)
>node_modules フォルダのように依存関係で１万を超えるファイルがプロジェクト毎に作られるという状況もザラになりました

.pyc は一般的には、ソースファイルと同じフォルダではなく、その下の__pycache__フォルダにできませんか？
(普通に使っていて直接ファイルと同じところに出来ます？）

C/C++もコマンドやメイクファイルでそう記述してるならまだしも、
「通常は、ソースファイルとは異なるフォルダに出す設定」にするのが一般的です。
そうしないと、ソースファイルのフォルダに直接無関係なファイルがわらわら出来上がることになるわけですし

キャッシュファイルが一般的に有効なのは、「比較的巨大で多数のファイル＆多段の読み込みネスト」関係にあるライブラリがある場合に、
その初動のコンパイル時間をスキップできる、というところが主な目的ですが、
私は秀丸のjsmodeにはrequireの機能があるべき、と言ったものの、実際のところは、requireの機能が搭載されなかったため、
そういった「標準的ともいえる多段なライブラリ」が読み込まれるような状況の構築はないだろう、と推察します。

キャッシュファイルがオプションで出来ることは賛成しますが、
「ユーザーが管理するファイル」と「実行時に生成されるファイル」が「一緒のフォルダに並列に」展開されている、
というのはあまりよろしいとは言い難いです。

「直接管理を意識させる」という視点に変えれば、キャッシュではなくいわゆる「マニュアルでコンパイル」する、に近い考え方(結局出来上がるバイトコードファイルとしては今と同じ）ですが、
秀丸の出すバイトコードの秀丸のバージョン間での互換性次第でしょう。
これが秀丸のバージョンが上がると頻繁に変化しているようであれば、ほとんど意味がないですし、
逆にバイトコード規則が変わったことはここ10年以上ない、とかなら「あり」かなぁ、と思います。

[ △ ]

RE:10404 コメント行による速度の影響

No.10408

秀丸担当 さん　24/06/03 14:32　[ コメントを投稿する ]

自動起動マクロでないマクロをキャッシュ化するには、execmacroを使います。
起動するマクロはtest.macで小さいファイルとして、大き目の本体をtest2.macとすると、execmacroは通常は以下のようになります。
execmacro "test2.mac";
これを
execmacro "test2.mac.cache";
のように書くと、自動でtest2.macを元にtest2.mac.cacheを生成したり利用したりします。
キャッシュファイルを生成する、といったような操作は必要ではないです。
使う側は生成するとか利用するとかを気にする必要は無いです。
ただ同じフォルダに.mac.cacheができるだけです。

実行元のtest.macをキャッシュ化する方法はありません。
やるとしたら、自動起動マクロのようにオプションで全てのケースでキャッシュを作るかと思いましたが、皆様のご意見を参考にすると、議論の余地があるようで、やめておいたほうがいいのかもしれません。

オーバーヘッドというのは、キャッシュのファイルを比べたりキャッシュファイルを読み込んだりします。
ユーザーは気にする必要は無いですが、キャッシュファイルを使わないと判断された場合にただ無駄になるケースがあるということでした。
でもほぼデメリットよりメリットが上回るので、使うに越したことはないです。

総合すると、記述するのは.macのままで、マクロフォルダ等には.mac.cacheができたりはせず、どこかにキャッシュが作成され自動で管理され、何にも気にする必要が無いのが一番いいのだと思います。
それを作るとすると、オプションで全部ONにするだけの案よりかは手の込んだことになるので、そういうネタとしておこうと思います。

[ △ ]

RE:10408 コメント行による速度の影響

No.10409

western さん　24/06/03 19:23　[ コメントを投稿する ]

execmacro "test2.mac.cache";

とマクロ命令で指定した時と同じように、
マクロ登録ダイアログのファイル名部分で拡張子を追記しておくことで
挙動が同じようになってくれると統一感が出て嬉しいです

[ △ ]

RE:10408 コメント行による速度の影響

No.10410

楽になりたい さん　24/06/05 00:43　[ コメントを投稿する ]

execmacro の記述を変えればキャッシュ化できるのですね。

> キャッシュのファイルを比べたりキャッシュファイルを読み込んだりします。

.mac から作成されたキャッシュファイルか否かを確認する。という意味ですか？
これはキャッシュ化する時のフローで不要にすることができると思います。
・エラーが無ければキャッシュ化して上書き。
・エラー有ったらキャッシュファイルを削除。
ただし、違う.macから作成されたキャッシュファイルをコピペしてリネームするという抜け道は残りますが、希望した処理結果にはならないので放置してもいいとも思えます。

[ △ ]

RE:10410 コメント行による速度の影響

No.10411

こみやんま さん　24/06/05 09:48　[ コメントを投稿する ]

>・エラーが無ければキャッシュ化して上書き。
>・エラー有ったらキャッシュファイルを削除。
>ただし、違う.macから作成されたキャッシュファイルをコピペしてリネームするという抜け道は残りますが、希望した処理結果にはならないので放置してもいいとも思えます。

キャッシュファイル(バイトコード)を実行する度に「必ず毎回」作ってしまうのであれば、
それこそ「execmacro」でループしまくっている、
といった時以外は意味がなくなってしまいます。

(むしろ「バイトコードをファイルに吐き出す時間」の分マイナスになるw)

```
バイトコードを決して毎回出力する「ことなく」
現在の.macに対して「正しいキャッシュファイル」であることを、
バイトコード化にかかる時間よりも「はるかに短い時間」で判定する。
```

これが出来るか否かがキャッシュファイルがメリットが多いかそうでないか、分かれ目です。

基本的には「キャッシュファイル」の中に
「①以前の.mac ファイルサイズ情報 ②以前の.macのファイルの最終更新時刻情報 ③以前の.macの内容のサマリー的なGUIDやハッシュに近い情報」

このあたりを今の.macと①②③を判定、
食い違った段階で、バイトコードを生成してキャッシュファイルとして上書き、
そうでなければ、現在のキャッシュファイルを採用。

現状でも「これにある程度近い動作」になっているハズです。

どこまでやるかですが、「判定に時間がかかったらそもそも意味がない」ので、大抵似たようなものです

[ △ ]

RE:10411 コメント行による速度の影響

No.10412

こみやんま さん　24/06/05 09:59　[ コメントを投稿する ]

あ、いや、保存時だけ作る、という考え方ですか。
あぁ、ありかも...?

[ △ ]

RE:10412 コメント行による速度の影響

No.10422

楽になりたい さん　24/06/09 00:43　[ コメントを投稿する ]

> バイトコード化にかかる時間よりも「はるかに短い時間」で判定する。
> これが出来るか否かがキャッシュファイルがメリットが多いかそうでないか、分かれ目です。

そういう意味で提案させて頂きました。
毎回.macからキャッシュを作成して一致するかどうかで判定する。という事を毎回やっていてはキャッシュ化した意味がありません。

ですので

> あ、いや、保存時だけ作る、という考え方ですか。

の方がシンプルで効果的なのではないか。と考えて提案させて頂いた次第です。
私のように『どうやって作るの？』と質問をされることもなくなるでしょう。
キャッシュを作る／作らないの選択権ぐらいはユーザーに残してあげた方が親切かもしれませんが。

[ △ ]

[ 新規に投稿する ]