性能強化案１ データのパケット化を検討する

[berryzplus]

前置き

#430 (comment)

x64対応の過程で気付いた性能強化案の共有です。
やるかどうか、また、具体的にどうするかは別の話として、
これをやると何が嬉しいかについて書きます。

提案の内容

内部データの持ち方を変えることにより、大容量データに対応します。

現在：　連続したメモリ領域にファイル全体を読み込む構造になっています。
　↓
変更後：小分けで確保したメモリ領域にファイルの一部を読み込むようにします。

メリット

メモリ確保単位を小さくするとこによる効果として、
実装メモリ容量と無関係に大容量データに対応できるようになります。

メモリ容量が4GBの端末で、4GBのファイルを開くことは不可能ですが、
データをパケット化する方式なら実装メモリ容量を超えるデータを扱えるようになります。

デメリット

データ保持に利用している DSL の大半を書き換える必要があります。
※DSL = Domain Specific Language

CLayoutMgr などのサクラエディタの心臓部を書き換える大改修になります。

対応計画

当面は計画なし 😢

[KENCHjp]

大きなファイルを操作するときだけ、私は、xyzzyってエディタを使っています。
http://xyzzy-022.github.io/
いつの間にかOSSになってますね(笑)
このエディタは2GBを越えるファイルもサクサク開いてくれます。
xyzzyの実装は見ていませんが、 https://docs.microsoft.com/ja-jp/dotnet/standard/io/memory-mapped-files こんな機能が気になってます。

[berryzplus]

大きなファイルを操作するときだけ、私は、xyzzyってエディタを使っています。
http://xyzzy-022.github.io/

目的特化で別アプリを使うのは正しいと思っています。

必要な分だけメモリを確保するために、バッファの使い方を工夫してそうに見えました。
ソースコード、ファイル名しか見てませんが 😄

https://docs.microsoft.com/ja-jp/dotnet/standard/io/memory-mapped-files こんな機能が気になってます。

メモリマップトファイル、この機能単体では「既に使っている」なんです。

sakura.ini のデータをプログラム間で使いまわすための「共有メモリ」の基盤技術がメモリマップとファイルです。windows標準の「iniファイル」の後継は「レジストリ」にあたるんですが、レジストリはシステムレベルで確保された共有メモリに展開されたデータベースです。レジストリを使わず、レジストリ同等の高速アクセスを考えた結果「メモリマップトファイルを使う」という選択になったんだと思います。

[KENCHjp]

レジストリを使わず、レジストリ同等の高速アクセスを考えた結果「メモリマップトファイルを使う」という選択になったんだと思います。

なるほどです、基礎情報はあるって感じなんですね。今のサクラの構造としてこれを使うかどうかはべつかもしれませんが。

[berryzplus]

memory mapped file

これを発音に近しく書けば「メモリマップトファイル」。
しかし、気を抜くと「メモリマップとファイル」になってしまう危険なネーミング。
そういえば「タッキーと翼」の片割れが裏方宣言したとかしないとか 😢

[berryzplus]

モチベーションが尽きたので閉じてしまいます。 #1394