C#なのですが…

[バグ]

ディレクトリの一括削除を行うクラスを作っているのですが、あまりにも遅いんで、何か高速で行う方法は無いものかと思い、質問させてもらいます。

いまのやり方は、下記を使用しております。

Directory.Delete(szPath, true);

１つや２つの小容量ファイルならばいいのですが、１００を超えたり、容量も何百メガになる事もあるので、できる限り高速で処理したいので、何か別の良い方法がありましたら、教えていただけないでしょうか？

ちなみに、総合計約２０００の空のテキストファイル＆フォルダを消すのに、５０秒弱掛かっています。

[YuO]

基本的に，それより早くなることはないでしょう。

可能性があるとすると，全部をC/C++で書いてP/Invokeでしょうか。
manage/unmanageのモード遷移が減る可能性があるので，若干早くなるかもしれません。

[バグ]

そうですか…残念です。
ソフトの仕様上、あまり長い間処理を占有する訳にもいかないので、苦肉の策ではありますが、別スレッドでいくつかファイルを削除する度に処理を中断するように作り変えようと思います。

返信、ありがとうございましたm(__)m

[Justy]

　これって Directory.Deleteを"１回だけ"使っての全削除ですか？

・　普通にエキスプローラ上から削除
・　C++で書いた削除ツールで削除
・　bat（バッチ）で削除

　と比べてどれくらい遅いのでしょうか？

[バグ]

年・月・日がそれぞれフォルダになってまして、指定された日数を過ぎたフォルダを削除するというものなんです。

2007→05→14

こんな感じで、全検査していきまして、削除対象のフォルダのみを削除するようにしています。

エキスプローラーから一括削除した場合は一瞬ですね。ただ、削除するかしないかの検索処理を行っていないので、比較対象にはならないと思います…(^_^;)

[Justy]

　なるほど。
　実際のところ、削除処理で時間を消費しているのかどうか、それだとちょっとわからないですね。

　ボトルネックをきちんと特定した方がいいかと思います。
　各処理のパフォーマンスを測定するとか、デバッガで処理が重そうな時に止めてみてどこで止まるかを
見てみる、とか。
（特に文字列を扱っていたりすると、気をつけないと激重になっている可能性があったりします）

[バグ]

削除部分を無効にして、検索のみを有効にしてみたところ、１秒程で処理が終了しました。
やはり、削除部分で時間わくっているようです。
一通り見直したのですが、文字列に関する処理にかなり無駄な部分があったので、組み直してみると、５０秒掛かっていた処理が４５秒に縮まりました。
Justyさんの言われたとおり、文字列の処理を多用するのはよくないみたいですね(;^_^A
まぁ、どちらにせよ、ファイル検索＆削除に一度に使用しても良い時間は最大１秒なので、結局は分割処理にせざるをえないんですけどね(^^ゞ

[Justy]

＞やはり、削除部分で時間わくっているようです
　そうですか。
　結構 Directory.Delete()をコールする回数が多い、ってことでしょうか。
（日付で削除なら数十・数百のディレクトリを削除ってこともありますよね）

　となるとまぁ普通に考えて、削除処理を丸ごとスレッド化ですかね。
　あるいは別の手段で高速な削除ツールを作れるなら、そっちに任せてしまうとか。


＞文字列の処理を多用するのはよくないみたいですね
　最初の頃、C#の stringは C++の std::stringとは違うということに気付かなくて、
全部 stringで組んでいたのですが、StringBuilderによる文字列の構築に
切り換えたら３０秒以上かかっていた処理が１～２秒で終わった、なんてことがありました。
　もう唖然としましたよ（ｗ

[バグ]

えっ！？std::stringと同じだと思って、stringしか使ってなかったです(^^ゞ
また見直してみます(;^_^A

[Justy]

　stringは 文字列を扱うということでもちろん使うのですが、その
文字列の構築・・・というか文字列の連結にはStringBuilderを使うと
高速になります。
　特に大量の文字列処理をするときは必須とも言えます。

　で、使うときは StringBuilderから stringに変換する、と。


文字列処理を高速に行う: .NET Tips: C#, VB.NET, Visual Studio
http://dobon.net/vb/dotnet/string/stringbuilder.html

C# の StringBuilder と += による文字列連結の速度比較
http://sonic64.com/2005-11-30.html