« 2009年2月 | トップページ | 2009年4月 »

2009/03/23

高速ファイルコピー機能は必要でしょうか?

前回のブログからの続きです。

前回測定した結果では以下のような結論になりました。
高速ファイルコピーは、バッファの2倍以上のファイルサイズで効果的に動作し、ファイルのコピー時間を約2割時間短縮できる
(高速ファイルコピーの効果は環境に依存します。今回の結果は一例とお考えください)

皆さんはこの結果をどう思いますか?
ユーザーさんからいただくメールなどを拝見していると、何となく高速ファイルコピーに過剰な期待を持っているように感じます。
前述の通り、私はコピー時間が2割程度短くできるだけであれば、バックアップ全体から見るとさほど時間の短縮につながらないという判断で、前回はこの機能の公開を見送りました。
なぜせっかく作った機能を非公開にするのか、とお思いになる方がいらっしゃるかもしれません。
確かにその通りなのですが、ソフトウェアに限らず、どんなものでもシンプルな方が操作が簡単で、不具合も少なくなります。シンプルイズベストです。

ただ、ユーザーが扱うファイルの容量が増えてきているのも事実です。
そこで、ユーザーの皆さんにご意見をお聞きしてみようと思った次第です。
どうでしょう。高速ファイルコピー機能は必要でしょうか?

もしよろしければご意見をお寄せください。

高速ファイルコピーは必要でしょうか?

またその理由はなんでしょうか?
普段どのくらいの容量のファイルをコピーしていますか?

| | トラックバック (0)

2009/03/20

高速ファイルコピーベンチマーク考察

前回からの続きです。

エクスプローラー、BunBackup(標準)、BunBackup(高速)の比較です。

エクスプローラーはOSのAPIを利用していると思いますので、基本的にはBunBackup(標準)と同じはずです。ただし、コピーの前処理や後処理方法が違うと思いますので、その分が多少差に表れていると思います。

今回意外だったのは、エクスプローラー、BunBackup(標準)は測定結果のばらつきが大きいということです。通常は3回測定したものを平均 していますが、エクスプローラー、BunBackup(標準)の場合は、それよりも多く測定し、大きく外れたものをはずして平均しています。はっきりした ことはわかりませんが、OS側の状況によって影響を受けやすいのかもしれません。BunBackup(高速)や他の高速ファイルコピーソフトは比較的安定 した速度になっています。

高速ファイルコピーの効果は環境に大きく依存します。以下の結果は一例とお考えください。
以下はエクスプローラーを100としたときの数値です。

パターン1
526KBのファイルを1007個バックアップしたとき

エクスプローラー 100
BunBackup(標準) 92
BunBackup(高速) 90

基本的に、高速ファイルコピーはオーバーヘッドが大きいので、小さなファイルのコピーには向きません。
バックアップの場合は、小さなファイルと大きなファイルが混在することが多いため、BunBackup(高速)では小さいファイルでも遅くならない工夫をしています。その効果が多少現れているのではないかと思います。

パターン2
2MBのファイルを483個バックアップしたとき

エクスプローラー 100
BunBackup(標準) 93
BunBackup(高速) 90

ファイルサイズが2MBではまだバッファが有効に働きませんので、基本的にはパターン1と同じ傾向です。
ちなみにBunBackup(高速)は、一度に読み書きするバイト数は4MBです。
パターン3
4MBのファイルを279個バックアップしたとき

エクスプローラー 100
BunBackup(標準) 105
BunBackup(高速) 93

ファイル容量が4MBではまだ大容量バッファが有効に働きませんので、基本的にはパターン1と同じ傾向です。

パターン4
10MBのファイルを98個バックアップしたとき

エクスプローラー 100
BunBackup(標準) 93
BunBackup(高速) 65

このあたりから大容量バッファが有効にきき、マルチスレッドも効率よく動作するようになります。
今回の測定ではこの数値がマックスです。

パターン5
71MBのファイルを18個バックアップしたとき

エクスプローラー 100
BunBackup(標準) 101
BunBackup(高速) 78

パターン4よりも遅くなっているのはメモリ効率の関係かもしれません。
バッファサイズを調整すればもう少し速くできるかもしれませんが、今回は全てのパターンでバッファサイズを固定して測定しています。

これ以上大きなファイルも試してみましたが、おおよそパターン5と同じ傾向でした。
こちらでバッファサイズをいろいろ変更してみましたが、単に大きくすれば速くなるという訳ではなく、試した限りでは一度の読み書きは4~8MBがベストでした。

このテスト結果からわかることは以下の通りです。
  • 小さいファイルにはあまり効果はない
  • 高速ファイルコピーはおおよそ20%前後時間を短縮できる
  • 高速ファイルコピーの効果は最大で35%減
  • バッファサイズは大きいほど速い訳ではない(一度の読み書きは4~8MBが最適)

つまり、バッファの2倍以上のファイルサイズで効果的に動作し、約2割時間短縮できる、と考えられます。
たとえば、コピーするファイルが1GBあり、通常ファイルコピーに1分かかるとすると、高速ファイルコピーで48秒にすることができ、12秒節約すること ができます。この12秒短縮が重要なのかどうかは微妙だと思いますが、コピーするファイルが数GBあるのであれば、それなりに効果があると判断できるかも しれません。
(あくまでも今回測定した条件によるものです。短縮時間は環境によります)

次のブログに続きます。

| | トラックバック (0)

2009/03/17

高速ファイルコピーベンチマーク

前回からの続きです。

では、実際高速ファイルコピーすることで、どの程度時間が短縮できるか測定してみましょう。

比較するソフトは以下の通りです。
  • エクスプローラー
  • BunBackup(標準)
  • BunBackup(高速)
  • FastCopy
  • Fire File Copy
  • TeraCopy

コピーする条件は以下の通りです。

  • OSは、Windows XP SP3
  • 内蔵HDDからUSB接続外付けHDDにファイルをコピーする
  • コピー先のフォルダは空になっている
  • 各ソフトは全て初期値でコピーする

BunBackup(高速)の初期値は、一度に読み書きするバッファは最大4MB、これを最大12MB分のバッファに記録します。

以下のパターンでコピーします。

  • 526KBのファイルが1007個(パターン1)
  • 2MBのファイルが483個(パターン2)
  • 4MBのファイルが279個(パターン3)
  • 10MBのファイルが98個(パターン4)
  • 71MBのファイルが18個(パターン5)
 
以下の手順でファイルをコピーします。
  1. パソコンを起動する
  2. ソフトを起動する
  3. パターン1でコピーする
  4. パターン2でコピーする
  5. パターン3でコピーする
  6. パターン4でコピーする
  7. パターン5でコピーする
  8. パソコンをシャットダウンする
これをソフトごとに繰り返します。
同じ測定を3度行い平均値を出します。大きく外れる数値があった場合は、それを除いて再測定します。
時間の測定は、ソフトで時間を表示できる場合はそれを採用し、時間を表示できない場合はストップウォッチで測定しています。
上記の条件で測定した結果が以下の通りです。
数値はバックアップにかかった秒数です。

パターン1
526KBのファイルを1007個バックアップしたときの時間(秒)
Pattern1_2




パターン2
2MBのファイルを483個バックアップしたときの時間(秒)
Pattern2




パターン3
4MBのファイルを279個バックアップしたときの時間(秒)
Pattern3




パターン4
10MBのファイルを98個バックアップしたときの時間(秒)
Pattern4




パターン5
71MBのファイルを18個バックアップしたときの時間(秒)
Pattern5

次のブログに続きます。

| | トラックバック (0)

2009/03/16

高速ファイルコピー

次のバージョンを検討していますが、アンケートで「FastCopyのような高速ファイルコピー」とう要望がありましたので、これについてユーザーさんのご意見を聞いてみようかと思い、ここに書いてみます。

ファイルコピーを高速化する方法はいくつかあると思いますが、一般的な方法としては以下の二つがあります。
  • 大容量バッファを使用し、一度に読み書きする容量を増やす(大容量バッファコピー)
  • ファイルを読むスレッドと書くスレッドを別々にして効率よくコピーする(マルチスレッドコピー)
実は何年か前にBunBackupにこれらの機能を実装したことがあります。(この機能は公開していません)
高速ファイルコピーは確かにコピーにかかる時間を短縮できます。
ただ、環境によってはそれほど速くならないのです。

大容量バッファコピーは、同じドライブ内のコピーであれば効果的なのですが、異なるドライブへのコピーはそれほど速くなりません。
マルチスレッドコピーは、コピー元とコピー先のアクセス速度が同じで、それぞれが完全に独立して動作することができれば、理論的には半分の時間でコピーできるはずです。しかし、実際には完全に独立して動作することはできませんので、時間が半分になる訳ではありません。
以前行った測定では、異なるドライブ間では1~3割ほどの時間を短縮できることがわかりました。

環境によりますが、差分バックアップの場合、初回のバックアップを除くとコピー時間の占める割合はそれほど多くはありません。
差分バックアップは以下の処理をします。
  1. バックアップ元にあるファイルの情報を取得する
  2. バックアップ先にあるファイルの情報を取得する
  3. バックアップ元と先のファイルを比較し、コピーするファイルを抽出する
  4. ファイルをコピーする

このように、コピーだけでなく1~3の処理にも時間がかかります。つまりコピー時間だけを短縮しても全体的にはそれほど短縮できない可能性があります。

それでも、時間が短縮できるのならその機能が欲しいという方もいらっしゃるかもしれません。
しかしこれにはデメリットもあります。

一つは、環境によっては高速ファイルコピーの方が遅くなるということです。
OSが用意しているファイルコピーはそれほど効率が悪くありません。そのため条件によっては高速ファイルコピーの方が遅くなるのです。たとえば小さなファイルが大量にある場合は通常のコピーの方が速い場合があります。

もう一つは、コピーの処理が複雑になるということです。
実はマルチスレッドコピー自体は複雑ではありません。問題は何らかの理由によりコピーできない場合、そのエラー処理が複雑になるということです。処理が複雑になるということは不具合が発生する確率が高くなるということを意味します。

このようにメリットとデメリットを考え、結果的に高速ファイルコピー機能の公開は見送りました。

ただ、最近少し思うところがありました。
最近ユーザーさんの環境をお聞きしていると、一度に扱うファイルの容量が増えているように感じます。
ユーザーが意識せずに大きなファイルを扱っている場合もあるようです。たとえば、メーラーのファイルは人によっては数GBになっています。

このようなことから、ユーザーさんのご意見を聞いて、高速ファイルコピー機能を再考してみることにしました。
まず高速ファイルコピーすることで、どの程度時間が短縮できるかを把握するために、改めてベンチマークを取ってみました。
ついでに、他の高速ファイルコピーソフト、FastCopy、Fire File Copy、TeraCopyと比較してみました

次のブログに続きます。

| | トラックバック (0)

2009/03/09

BunBackup 英語版 Ver.3.21b1 公開

BunBackup 英語版 Ver.3.21b1 を公開いたしました。

動作テストのご協力よろしくお願いいたします。
不具合を発見された場合や、ご意見・ご要望などがありましたらメールでお知らせください。

今回の主なバージョンアップ内容は以下の通りです。

  • BunBackup Ver.3.21をベースに作成

| | トラックバック (0)

2009/03/03

BunLogMail Ver.3.20b4 公開

BunLogMail テスト版 Ver.3.20b4を公開いたしました。

動作テストのご協力よろしくお願いいたします。
不具合を発見された場合や、ご意見・ご要望などがありましたらメールでお知らせください。

今回の主なバージョンアップ内容は以下の通りです。

  • 省メモリバックアップのログで2GB以上のファイルがあった場合にエラーになるのを修正

| | トラックバック (0)

2009/03/02

BunBackup Ver.3.21 公開

BunBackup Ver.3.21を公開いたしました。

テスト版の動作テストにご協力いただいたユーザーの皆さんありがとうございました。

今回のバージョンアップの主な変更点は以下の通りです。

  • 高速ファイルチェック機能使用時、一つのファイルでサイズが2GBを超えるものがあるときにエラーが出るのを修正
  • 省メモリバックアップ時のログ表示時、一つのファイルでサイズが2GBを超えるものがあるときにエラーが出るのを修正
  • コマンドラインオプションのAUTO使用時、設定によってはメインウインドウが表示される不具合を修正
新しいBunBackupをご使用になってのご意見・ご要望、不具合のご報告お待ちしております。
今後ともBunBackupをよろしくお願いいたします。

| | トラックバック (0)

« 2009年2月 | トップページ | 2009年4月 »