1

時々接続されるクライアント アプリケーションのサーバーからファイルを同期するアプリケーションで 、#ziplib (ここにあります) を使用しています。

私の質問は、このアルゴリズムでは、ファイルの実際の圧縮を行うために実行時間を費やす価値があるのはいつですか? おそらく、小さなテキスト ファイルが 1 つだけ同期されている場合、圧縮にかかる時間は転送のサイズを十分に縮小せず、実際にはプロセス全体の速度を低下させます。

圧縮時間プロファイルは、ファイルの数、ファイルの種類、およびそれらのファイルのサイズに基づいて変化するため、いつファイルを圧縮する必要があり、いつそれらをそのまま渡す必要があるかをプログラムで発見する良い方法はありますか? ? 私たちのアプリケーションでは、写真の種類とサイズが変わる可能性がありますが、ほとんどの場合、ファイルは写真になります。

私はまだ実際のファイル転送ロジックを書いていませんが、System.Net.WebClientこれを行うために使用することを期待していますが、実行時間を節約するための代替手段にもオープンです。

更新: この議論が発展するにつれて、「圧縮するか、圧縮しないか」は間違った質問ですか? System.Net.WebClient古い方法を圧縮された WCF トラフィックまたは類似のものに置き換えることに焦点を当てる必要がありますか? このユーティリティのデータベース同期部分では、Microsoft Synchronization Framework と WCF が既に使用されているため、私はそれを受け入れます。ネットワーク トラフィックを制限するために今できることは、クライアントにとって非常に大きなものになるでしょう。

4

3 に答える 3

2

ファイルを圧縮することが有用かどうかを判断するには、とにかくファイルを読み取る必要があります。その上にあるときは、それを圧縮することもできます。

ファイルを読み取らずに無駄な圧縮を防ぎたい場合は、他のプロパティに基づいて事前に決定することができます。

たとえば、ファイルの拡張子とサイズに基づいて、有用かどうかを判断する「アルゴリズム」を作成できます。したがって、1 KB を超える .txt ファイルは圧縮できますが、.jpg ファイルはファイル サイズに関係なく圧縮できません。しかし、そのようなリストを作成するのは大変な作業です (ブラックリストまたはホワイトリストを作成して、リストにないすべてのファイルを cq 拒否できるようにすることもできます)。

于 2011-11-02T12:49:13.807 に答える
1

おそらく十分な CPU 時間があるので、唯一の問題は、縮小するかどうかです。

ファイルを減らすことができれば、(ディスクとネットワーク) I/O に保存されます。それは非常に迅速に利益を上げます。

残念ながら、写真 (jpeg) は既に圧縮されているため、あまり効果が見られない可能性があります。

于 2011-11-02T12:41:52.730 に答える
0

独自の非常に単純なヒューリスティック分析を作成し、次のファイル処理ごとに再利用できます。収集された統計は、再起動の合間に効率を維持するために保存する必要があります。

基本的にインターフェース：

enum FileContentType
{
  PlainText,
  OfficeDoc,
  OffixeXlsx
}

// Name is ugly so find out better
public interface IHeuristicZipAnalyzer
{
   bool IsWorthToZip(int fileSizeInBytes, FileContentType contentType);
   void AddInfo(FileContentType, fileSizeInBytes, int finalZipSize);
}

次に、使用して圧縮されたファイルに関する情報を追加することで統計を収集しAddInfo(...)、それに基づいて、呼び出して次のファイルを圧縮する価値があるかどうかを判断できますIsWorthToZip(...)

于 2011-11-02T12:41:30.343 に答える