コメント行による速度の影響 - 秀丸エディタマクロ作者会議室 - スレッド10384, 2024/05/29

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

楽になりたい さん　24/05/29 02:19

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

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

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

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

でるもんたいいじま さん　24/05/29 03:46

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

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

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

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

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

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

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

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

western さん　24/05/29 10:22

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

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

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

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

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

・コメント文を読み飛ばす早さは 1MB の時に 14ミリ秒 *余分に*かかった (1,047,5
76バイトのコメント + 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 コメント行による速度の影響

でるもんたいいじま さん　24/05/29 11:37

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

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

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

☆　☆　☆

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

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

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

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

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

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 コメント行による速度の影響

でるもんたいいじま さん　24/05/29 11:58

> // gcc.exe -shared -o QueryPerformanceCounterL32.DLL QueryPerformanceCount
>erL.c

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

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

楽になりたい さん　24/05/29 23:15

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

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

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

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

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

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

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

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

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

秀丸担当 さん　24/05/30 09:35

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

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

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

楽になりたい さん　24/05/31 01:01

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

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

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

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

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

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

秀丸担当 さん　24/05/31 11:02

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

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

秀丸担当 さん　24/05/31 11:07

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

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

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

western さん　24/05/31 12:39

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

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

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

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

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

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

秀丸担当 さん　24/05/31 16:36

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

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

楽になりたい さん　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 コメント行による速度の影響

こみやんま さん　24/06/01 09:26

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

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

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

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

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

western さん　24/06/01 11:15

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

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

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

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

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

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

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

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

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

こみやんま さん　24/06/01 12:15

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

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

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

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

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

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

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

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

秀丸担当 さん　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 コメント行による速度の影響

western さん　24/06/03 19:23

execmacro "test2.mac.cache";

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

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

楽になりたい さん　24/06/05 00:43

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

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

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

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

こみやんま さん　24/06/05 09:48

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

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

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

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

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

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

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

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

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

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

こみやんま さん　24/06/05 09:59

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

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

秀丸担当 さん　24/06/05 12:05

キャッシュは、元の.macと.mac.cacheが確かに同じものかどうかを検証などをしてい
ます。
オーバーヘッドと書きましたが気分の問題で、それが何か問題になることは無いと思
います。

キャッシュの使い方が、キャッシュというよりソースとコンパイル結果で、EXEファ
イルのようにコンパイル結果だけを常に使うのであれば、また別の考え方だと思いま
す。
それがEXEやDLLのような実行時も高速化されたバイナリが生成さるのであれば有用だ
と思いますが、コンパイルといってもコメント除去と予約語などをバイトコードに置
き換える程度のもので、実行時は何も変わらないです。
なので、そもそも手動起動時はあまり効果無いですが、もしやるとしてもキャッシュ
までで十分だと思います。
マクロ内のループのときのexecmacroは、現状のキャッシュで効果があります。

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

楽になりたい さん　24/06/09 00:43

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

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

ですので

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

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