リハビリテーション
いろいろな意味でのリハビリテーションとして本日2025年7月7日にファイル同期ソフトウェアMulSync Version 2.1.2をリリースしました。
何かと使っていると同期対象チェック時間が気になるなということで今回のバージョンになった次第です。
ボトルネック
今まではそこまで使われるということを考慮していなかったのと、メールソフトやバージョン管理ソフトのデータベースの整合性のための同期動作制約に力を入れていたので同期対象チェックの中間でのファイル情報格納には単純なArrayListを使っていたのだけれどもメールやバージョン管理ソフトのファイルが増えてきたり、Vectorのレビューで紹介されるにあたって流石に速度的な見劣りが隠せないと感じてきた。
とはいえ、同期動作制約について見直すとディレクトリの順番が必要となるところは同期先と同期元がファイルとディレクトリというように衝突を抑えているところだけでレアケースだったのと、個人的な時間的に大きな時間を取れなくなったということで取得した回数の多い同期対象フォルダに格納されたファイルの格納をSortedDictionaryに変えてファイル・ディレクトリの有無の検索を見直してみた。
まず、これで目に見えて同期先ファイルが同期元にあるかどうかの検索という最大のボトルネックが解消されたので25%同期対象チェック処理の速度を削ることができた。当初はそこまでヘビーに使ったり認知度が出たりはしないだろうと思っていたので安直に考えていたが、裏目に出た格好である。
まだ行けるか
デバッグで確認をしてみるとString.StartsWith,String.EndsWithがなんか遅かったので、これを文字列の文字数を見て文字や文字列を切り出して比較してみると回数が増えると案外効果が出ていた。
ということでString.StartsWith,String.EndsWithを撲滅してみた。中でどのようなチェックをしているのかリファレンスソースを見るべきだろうけど、そのうちでよいか。
というわけで
今回のバージョンである。
処理中のデータ構造をもっとドラスティックに見直すとかすればよいのだろうが、時間がかかるのと十分に動いているものを直すのはリスクが伴うのでこんなところである。
個人的にはUIを現代的にしたもののUIだけを作っているものもあるのだが、現状のものが十分動いているので手つかずである。今回のアルゴリズム変更も合わせて改めて十分に動いているものを置き換えることの難しさを思わされた次第である。
