1

我们在一个应用程序中使用#ziplib（在此处找到），该应用程序为偶尔连接的客户端应用程序从服务器同步文件。

我的问题是，使用这种算法，什么时候值得花费执行时间来进行文件的实际压缩？据推测，如果只同步一个小文本文件，压缩时间将不足以减少传输的大小，实际上会减慢整个过程。

由于压缩时间配置文件将根据文件数量、文件类型和这些文件的大小而改变，有没有一种好方法可以通过编程方式发现何时应该压缩文件以及何时应该按原样传递它们? 在我们的应用程序中，文件几乎总是照片，尽管照片的类型和大小可能会发生变化。

我还没有编写实际的文件传输逻辑，但希望使用它System.Net.WebClient来执行此操作，但我也愿意使用替代方案来节省执行时间。

更新：随着讨论的发展，“压缩还是不压缩”是错误的问题吗？是否应该将重点放在System.Net.WebClient用压缩的 WCF 流量或类似的东西替换旧方法？该实用程序的数据库同步部分已经使用 Microsoft Synchronization Framework 和 WCF，因此我当然对此持开放态度。我们现在可以做的任何限制网络流量的事情对我们的客户来说都是巨大的。

4

3 回答 3

2

To determine whether it's useful to compress a file, you have to read the file anyway. When on it, you might as well zip it then.

If you want to prevent useless zipping without reading the files, you could try to decide it on beforehand, based on other properties.

You could create an 'algorithm' that decides whether it's useful, for example based on file extention and size. So, a .txt file of more than 1 KB can be zipped, but a .jpg file shouldn't, regardless of the file size. But it's a lot of work to create such a list (you could also create a black- or whitelist and allow c.q. deny all files not on the list).

于 2011-11-02T12:49:13.807 回答
1

You probably have plenty of CPU time, so the only issue is: does it shrink?

If you can decrease the file you will save on (Disk and Network) I/O. That becomes profitable very quickly.

Alas, photos (jpeg) are already compressed so you probably won't see much gain.

于 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 回答