こんばんわ、仔細の情報をありがとうございます。
「もしかしてそうかな」とは思っていました。
手動クロールとの速度の差異ですが、例えば以下の構成で10,000個のファイルがFolder001からFolder100に分かれて入っているとして、
FolderRoot
|-FolderA
|-Folder001
|-Folder002
|- |
|-Folder100Folder001からFolder100を別のフォルダに移した場合と, FolderAを別のフォルダに移した場合とでは、同じ10,000個のファイルを移動させる場合でも、動作速度はだいぶ異なります。
手動クロールは後者と同等の動作をします。nikuyamaさんのご提案は、Folder001からFolder100を移動させた場合でも、ある一定数を処理したら、FolderA部分からの全体クロールに切り替えてはどうか、ということですね。そのやり方はこれまで何度か考えはしたのですが、Folder100では止まらず、Folder999まであったら逆に必要のないフォルダもクロールすることになってしまいます。
まあそれはともかく、結論的には現状では遅すぎて使い物にならないという話ですよね。
以前、まだわたしのノウハウもあまりなかったころ、多数のファイル形式をサポートするなかで、よく想定外の理由でエラーを起こしていました。それを改善するために、大量の情報を蓄積しながらクロールしているのですが、現在もその「大量の情報」は残したままです。現在では、ファイルが壊れているようなケースでないかぎり、原因不明のエラーということは少なくなってきたので(なくなったわけではないです)、もうすこしそのあたりの情報を減らしていくべきなのかもしれません。
手許の検証用の環境では、10,000ファイルを新規登録するのに、だいたい120秒くらいかかっています(ディスクキャッシュが効いた環境であり、実際にご利用いただく環境とは異なります)。すると、1ファイル12msくらいですので、あちらこちらの処理で1msずつ削って、6msになれば1分、3msになれば30秒、というところを詰めていくしかなさそうです。あるいは、わたしの知らないまったく違う次元のやり方があるのか…。
それから、GUIの更新が遅い件ですが、「ファイルの取りこぼしがある」というご指摘への対策でしたので、今回のリリースではGUIの更新は大幅に遅くしてあります(3,000個のファイルの更新を確認したらGUIを更新する、としたと思います)。その結果が現れているものと思います。これは緩和するようにします。