什么时候才值得花时间去压缩文件呢?

本文关键字：压缩 文件 时间 值得 什么时候 | 更新日期: 2023-09-27 18:13:00

我们在一个应用程序中使用#ziplib(在这里找到)来为偶尔连接的客户端应用程序从服务器同步文件。

我的问题是，有了这个算法，什么时候才值得花时间去做实际的文件压缩?假设，如果只同步一个小文本文件，压缩的时间不足以减少传输的大小，实际上会减慢整个过程。

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

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

更新:随着讨论的深入，"压缩还是不压缩"是一个错误的问题吗?应该把重点放在用压缩的WCF流量或类似的东西替换旧的System.Net.WebClient方法上吗?这个实用程序的数据库同步部分已经使用了Microsoft同步框架和WCF，所以我当然对此持开放态度。我们现在所能做的任何限制网络流量的事情对我们的客户来说都将是巨大的。

什么时候才值得花时间去压缩文件呢?

要确定压缩文件是否有用，无论如何都必须读取该文件。当你在上面的时候，你最好把它拉上。

如果您想防止在不读取文件的情况下进行无用的压缩，您可以尝试根据其他属性事先决定。

你可以创建一个"算法"来决定它是否有用，例如基于文件的扩展名和大小。因此，超过1kb的.txt文件可以被压缩，但无论文件大小如何，.jpg文件都不应该被压缩。但是创建这样一个列表需要大量的工作(你也可以创建一个黑名单或白名单，并允许c.q.拒绝所有不在名单上的文件)。

您可能有足够的CPU时间，所以唯一的问题是:它会收缩吗?

如果你可以减少文件，你将保存在(磁盘和网络)I/O。这很快就能盈利。

唉，照片(jpeg)已经被压缩了，所以你可能不会看到太多的增益。

您可以编写自己的非常简单的启发式分析，然后在下一个文件处理时重用它。为了保证重启之间的效率，应该保存收集到的统计信息。

基本接口:

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(...)

来确定是否值得压缩下一个文件。
相关文章：