強調表示のバッファーサイズについてNo.38026
fzok4234 さん 20/03/10 01:13
 
お世話になっております。

さて、現在の強調表示のバッファーサイズは128kbとのことですが、これは.hilight
ファイルの文字数に換算すると何文字分に相当するのでしょうか。


[ ]
RE:38026 強調表示のバッファーサイズにつNo.38027
秀丸担当 さん 20/03/10 10:18
 

hilightファイルの最大は、調べてみたところフラグ等の値を文字列化している関係
で誤差が出る場合がありました。
強調表示のメモリ使用量の最大は、厳密には、実際に定義される文字列で半角1文字
を1バイトとした文字列と、行頭のフラグ部分等の情報で2〜4バイトで、合計が126KB
(128KBではない)を超えるときにエラーとしていました。
hilightファイルの一行は、実際に定義される文字列はそのままのバイト数として、
フラグ等は数字部分の最大3桁(3バイト)とカンマ(1バイト)と改行CR+LF(2バイト)で、
1つの定義あたり4バイトくらいの差があるので、定義の仕方によって126KBよりも大
きくなる誤差が出るはずと思います。
4バイト差のある行が512個あれば、ちょうど128KBになって、それより多ければファ
イルサイズ自体はもう少し大きくなるはずと思います。(計算が合っていれば)

[ ]
RE:38027 強調表示のバッファーサイズにつNo.38031
fzok4234 さん 20/03/10 14:46
 
回答ありがとうございます。

とりあえず、多少の誤差はあるものの、ASCII互換文字なら1文字1Byteとみなしてよ
いという事で安心しました。

というのは、ある言語の.hilightファイルのサイズがもう少しで64KBになろうとして
いたので、もし秀丸が内部でUTF-16でバッファリングしていたら1文字2Byteで満杯に
なってしまうのではと心配だったからです。

とはいえ、.hilightファイルが1言語当たり128KBは少し少ないかもしれません。Powe
rShellやC#などの言語は現在も開発が進行中で今後も新しい文法がどんどん出てくる
ことが予想され、それに合わせて文脈で識別子を判断する正規表現パターンも次々に
継ぎ足していくことになります。

問題の64KB近くの.hilightファイルも今が折り返し地点で、容量の枯渇も時間の問題
です。

最近はPCの高性能化が進んできているため、このようなバッファーサイズは環境に合
わせてユーザーが変更できるようにした方が良いのではないでしょうか。

[ ]
RE:38031 強調表示のバッファーサイズにつNo.38035
秀丸担当 さん 20/03/10 16:28
 

強調表示のバッファに上限がある理由の1つとしては、ファイルタイプ別の設定とし
てレジストリに書き込んでいるということがあります。
バイナリ情報に分割して記憶していて、際限なくレジストリに書き込むのはどうかと
いうことと、増えるたびにレジストリの互換性維持が大変ということがありました。
別件でUnicodeの直接記述したいという話もあって、レジストリの互換性がどうもネ
ックになるので、V8.90でhilightファイル直接指定モードというのを追加しています。
とはいえ約128KBの上限はそのままなのですが、hilightファイル直接指定モードであ
れば、将来的にそういった制約から解放できる可能性があります。

他の理由としては、複雑な正規表現を書いていて遅いということで、増やせば増やす
ほど遅くなる一方ということになることがあります。
高速に処理できることを前提としているので、128KBとはいえ、既に多すぎるという
気がしています。
もし上限を増やすとしたら、先に遅くなる一方の問題をどうにかしたほうがいいと思
います。
1つの案として、遅いことを前提に、計算済みの行はキャッシュしておくという話が
ありました。手元で試しにやってみたりしているのですが、キャッシュが多すぎて逆
に遅くなるパターンなどがあって思案中です。

もう1つのネタとしてカラーマーカーにする方法がありました。そのうちの1つでco
lormarkerallfoundで範囲指定できるのをV8.92β1で追加したりしています。
これでもまだ手間ですが、一応とても遅い色付けを現在に行だけ任意のタイミングで
できたりします。
hilightファイルを指定してできたら、さらにいいかもしれません。
deletecolormarkerの追加はヘルプに書いてませんでした。追記しておきます。

マクロの例:
setcompatiblemode 0x20000;
$layer="mylayer";
deletecolormarker $layer, 0
    ,lineno,0,lineno,linelen2; //V8.92で追加

setsearch @"(aaa|bbb|ccc)",0x10;
colormarkerallfound 0x0000ff,-1,-1,0,0,$layer
    ,lineno,0,lineno,linelen2; //V8.92で追加

setsearch @"(xxx|yyy|zzz)",0x10;
colormarkerallfound 0xffffff,0xff,-1,0,0,$layer
    ,lineno,0,lineno,linelen2; //V8.92で追加

[ ]
RE:38035 強調表示のバッファーサイズにつNo.38037
fzok4234 さん 20/03/10 16:53
 
強調表示に限ったことではありませんが、やはりレジストリに、それもフォーマット
非公開のバイナリ形式でREG_BINARY型として設定が保存されていると、ユーザー側か
ら見ても取り回しが悪いです。最近のWindowsアプリでは、%AppData%フォルダーにXM
LやJSONなどの形式で設定を保存するものが増えてきており、PowerShellなどの処理
系から設定の一括バッチ編集が容易にできるようになっています。このことから、今
後のアップデートで徐々に設定を外部ファイルに保存するようにした方が良いかもし
れません。


[ ]
RE:38035 強調表示のバッファーサイズにつNo.38040
fzok4234 さん 20/03/11 04:53
 

>他の理由としては、複雑な正規表現を書いていて遅いということで、増やせば増や
>すほど遅くなる一方ということになることがあります。
>高速に処理できることを前提としているので、128KBとはいえ、既に多すぎるという
>気がしています。
>もし上限を増やすとしたら、先に遅くなる一方の問題をどうにかしたほうがいいと
>思います。

強調表示が重い処理とのことですが、マルチスレッドでの処理に対応させることはで
きないのでしょうか。

意図的に重い正規表現を強調表示に登録してタスクマネージャーでパフォーマンスの
確認をしたところ、CPUの使用率は10%程度しかなく、全てのコアがフル稼働していま
せんでした。当方の環境はCore i7-8700K 3.7GHz 6コア12スレッドですが、動作の重
さの割にはCPUパワーをかなり持て余している状態です。

また、1行の表示に数秒かかるほどの激重な正規表現でテストしてみましたが、実際
のレンダリングはウィンドウに表示されている部分の上部から1行ずつ行われている
状態でした。

このことから、いくつかの行をひとまとめにして1スレッドを割り当て、1スレッド当
たりの行数はウィンドウに表示されている行数をスレッド数で割ったものにして並列
で複数行を同時にレンダリングするという処理にした方が良いと思います。

それから以前にも申しましたが、一度強調表示した行は縦スクロールでウィンドウ外
に出ていくまで再計算しないことと、横スクロールでは一切再計算しないようにする
ことでも大分動作が早くなると思います。


[ ]
RE:38040 強調表示のバッファーサイズにつNo.38041
秀丸担当 さん 20/03/11 11:58
 

マルチスレッドにすることはスペルチェックでも似たようなことをしているので不可
能ではないと思いますが、対象が内容が変わり得るテキストそのものなので、不安定
になるリスクがあるかもしれません。
もしできたとして、編集した瞬間にはには色が付かないか、意図しない場所に色が付
く場合があるかのどちらかになると思います。
そういうこともできたらいい案として参考にさせていただきます。

[ ]
RE:38031 強調表示のバッファーサイズにつNo.38042
でるもんたいいじま さん 20/03/11 19:06
 
秀丸愛用者の「でるもんた・いいじま」です。横槍失礼します。

fzok4234さんの過去の投稿を読み返していて気付いたのですが、失礼ながら、とんで
もなく無謀なことに挑戦しようとしていませんか?

☆ ☆ ☆

というのも、以前にこのような投稿を書いておられますが、

> Subject: hidesoft.2:37561| [不具合]長い強調表示の定義が正常に読み込めない
> Date: Wed, 25 Sep 2019 13:26:01 +0900
>
> 現在、当方ではC#の強調表示の定義を作成しておりますが、
(中略)
> クラス名や変数名などの任意の文字列が使用可能な項目の強調表示は、
> \<(?!(add|break|case|catch|continue|default|do|else|finally| ....))\i\c*
> などというように予約語を回避するためにどうしても正規表現が長くなってしまい
>ます。
> このため現在作業が頓挫しております。

この文章が意図していることは、たとえばユーザが
string if="/dev/eth0";
のように書いた場合に「ifは予約語だから、変数名としては使えません」ということ
が瞬時にわかるようにしたい、ということですよね。

そのために、変数名やクラス名などを表す正規表現にはわざわざ「"if"の2文字だけ
の単語を除く」といった内容のことを全ての予約語について網羅的に手書きしていて、
その記述量が増える一方なので手詰まり気味、と。

☆ ☆ ☆

こういう手詰まりの場合に「マシンをパワーアップすれば(あるいはリソースの利用
効率を上げれば)解決するはずだ」という思考は通常、有効な打開策にはなりません。
根本的に発想法を変えないと、近い将来に確実に破綻します。

今回の場合、「ifは予約語だから◯◯色で表示する」というルールの優先順位を、
「^[a-zA-Z_][0-9a-zA-Z_]*$は変数・クラス等の名前だから◯◯色で表示する」とい
うルールの優先順位より高くしてやれば、それだけで済むことです。

それ以上のことをしたければ、C#のコンパイラが使っている文法解析エンジンを丸ご
とエディタに組み込むしかありません。Visual Studio Codeの開発チームあたりなら
本気でそれをやっていると思いますが、在野の一般アプリ(秀丸も)の開発体制はMi
crosoftやGoogle、Appleといった巨大企業のマンパワーには到底かないません。

☆ ☆ ☆

もうひとつ。

fzok4234さんは、マルチスレッド処理などの「割と最先端の」技法を「表面的には何
とか」使いこなせる腕をお持ちなのにもかかわらず、逆に、どんな言語にも共通の
「プログラミングとアルゴリズムの基本的な論理」の訓練が、失礼ながら根本的に不
足しているように思います。

日々のお仕事で大変だとは思いますが、そろそろ学習メニューの中に一定量の基礎ト
レーニングを組み込むことが避けられなくなってきたように思います。

頑張ってください。

P.S.
C#のコードを書く上での個別の課題(たとえば、括弧の対応関係が合っているかどう
かの検証作業)については微力ながら別解をご提示できると思います。もしご希望で
あれば、直メールで "delmonta@csc.jp" までお問い合わせください。

[ ]
RE:38037 強調表示のバッファーサイズにつNo.38043
でるもんたいいじま さん 20/03/11 21:02
 
こんにちは。秀丸愛用者の「でるもんた・いいじま」です。

> 強調表示に限ったことではありませんが、やはりレジストリに、
> それもフォーマット非公開のバイナリ形式でREG_BINARY型として
> 設定が保存されていると、ユーザー側から見ても取り回しが悪いです。

確かにこれはその通りなのですが、

> 最近のWindowsアプリでは、%AppData%フォルダーにXMLやJSONなどの
> 形式で設定を保存するものが増えてきており、

これが可能になったのは、安価なマシンでもそういう冗長なデータが扱えるようにな
ったからですよね。

ところが、秀丸はいまだにWindows98あたりもサポート対象にしています。(工場の
制御機器などではWindows98はバリバリ現役だと聞きます。PC-9801+MS-DOSのところ
もまだあるでしょう。)そうするとCPUはi486SX 33MHz、メモリは16MBくらいまで最
低ラインが下がります。

そしてこれはあくまで個人的な意見ですが、古参アプリの使命として、そういう古い
環境でも必要な作業がストレスなく行えることをきちんと保証しなければならないと
思います。

もちろん、そういうのは時代遅れだから新しいものをゼロから作り直そうよ、という
意見もあるとは思いますが、秀丸は誕生から既に30年弱、その間のノウハウの蓄積
(設定の中の「トラブル対策」の項目数を見ればお分かりいただけると思います)を
丸ごと捨ててまで新しいものに手を出す価値があるのかどうかは疑問です。多少不安
定でもいいから新しいものが使いたい、という人はVisual Studio Codeあたりに逃げ
ているでしょう。

> PowerShellなどの処理系から設定の一括バッチ編集が容易にできるように
> なっています。このことから、今後のアップデートで徐々に設定を
> 外部ファイルに保存するようにした方が良いかもしれません。

確かに、設定情報をテキストに書き出して編集する機能は私も欲しいです。ただ、こ
とエディタですから、設定をテキストファイルから毎回読み込むようにしてしまうと、
起動速度の問題の他に「設定ファイルに重大なミスがあった場合、その設定ファイル
(や、それを生成するスクリプト)を手作業で修正する手段が失われる」という重大
なリスクを含んでいます。Emacsの場合はそういうときのための -q というコマンド
ラインオプションがありますね。

なので、可読性の高いデータをバイナリ形式に変換してレジストリに流し込むコンパ
イラ、逆にバイナリ形式からテキストに書き出す逆コンパイラ、加えて今まで通りGU
Iでも設定変更が可能な設計、というのが落としどころのように思います。そうすれ
ば、バイナリデータの読み書きをするエンジンと、コンテンツを編集するエンジンと
を切り離すことができます。

で、秀丸の場合はレジストリのツリーが最大4箇所ありますから([日本語版,英語版]
×[64bit/32bitネイティブ,WoW64])、コンパイラ・逆コンパイラは秀丸マクロ自体
で実装するのが順当でしょうね。

[ ]
RE:38042 強調表示のバッファーサイズにつNo.38044
Iranoan さん 20/03/11 22:12
 
秀丸担当さんこんにちは
Iranoan です

本題については既に収束していますが
> それ以上のことをしたければ、C#のコンパイラが使っている文法解析エンジンを丸
>ごとエディタに組み込むしかありません。Visual Studio Codeの開発チームあたり
>なら本気でそれをやっていると思いますが、在野の一般アプリ(秀丸も)の開発体
>制はMicrosoftやGoogle、Appleといった巨大企業のマンパワーには到底かないません。
こちらの件について、ネタになりますが最近だと LSP (Language Server Protocol)
があります
これだと、秀丸で個々の言語に対応する必要なくなりつつ、IDE に近いことができる
ようになるかと

[ ]
RE:38044 強調表示のバッファーサイズにつNo.38045
秀丸担当 さん 20/03/12 10:48
 

>こちらの件について、ネタになりますが最近だと LSP (Language Server Protocol)
>があります
>これだと、秀丸で個々の言語に対応する必要なくなりつつ、IDE に近いことができる
>ようになるかと

情報ありがとうございます。
最近はそういうものもあるのですね。
調べてみようと思います。

[ ]