Когда стоит потратить время на выполнение, чтобы сжать файлы? - PullRequest
Новая
       71

Когда стоит потратить время на выполнение, чтобы сжать файлы?

1 голос
/ 02 ноября 2011

Мы используем #ziplib (найдено здесь ) в приложении, которое синхронизирует файлы с сервера для время от времени подключенного клиентского приложения.

Мой вопрос, с этим алгоритмом, когда становится целесообразным тратить время выполнения на фактическое архивирование файлов? Предположительно, если синхронизируется только один небольшой текстовый файл, время для архивирования не будет в достаточной степени уменьшать размер передачи и фактически замедлит весь процесс.

Поскольку профиль времени zip будет меняться в зависимости от количества файлов, типов файлов и размера этих файлов, существует ли хороший способ программно определить, когда мне следует заархивировать файлы, а когда я должен просто передать их как есть? В нашем приложении файлы почти всегда будут фотографиями, хотя тип фотографии и ее размер могут измениться.

Я еще не написал реальную логику передачи файлов, но ожидаю использовать System.Net.WebClient для этого, но я открыт для альтернатив, чтобы также сэкономить время выполнения.

ОБНОВЛЕНИЕ: По мере развития этой дискуссии вопрос «застегнуть или не застегнуть» неправильный вопрос? Следует ли сосредоточиться на замене старого метода System.Net.WebClient сжатым трафиком WCF или чем-то подобным? Часть этой утилиты для синхронизации баз данных уже использует Microsoft Synchronization Framework и WCF, поэтому я, безусловно, открыт для этого. Все, что мы можем сделать сейчас для ограничения сетевого трафика, будет огромным для наших клиентов.

Ответы [ 3 ]

2 голосов
/ 02 ноября 2011

Чтобы определить, полезно ли сжимать файл, вы все равно должны прочитать файл. Когда вы на нем, то можете и застегнуть его.

Если вы хотите предотвратить бесполезную архивацию без чтения файлов, вы можете попытаться решить это заранее, основываясь на других свойствах.

Вы можете создать «алгоритм», который решает, полезен ли он, например, на основании размера и размера файла. Таким образом, файл .txt размером более 1 КБ может быть заархивирован, а файл .jpg - нет, независимо от размера файла. Но создание такого списка - большая работа (вы также можете создать черный или белый список и разрешить c.q. запретить все файлы, отсутствующие в списке).

1 голос
/ 02 ноября 2011

У вас, вероятно, достаточно процессорного времени, поэтому единственная проблема: он уменьшается?

Если вы можете уменьшить размер файла, который вы сохраняете (Дисковый и Сетевой) ввод / вывод. Это становится выгодным очень быстро.

Увы, фотографии (jpeg) уже сжаты, так что вы, вероятно, не увидите большого выигрыша.

0 голосов
/ 02 ноября 2011

Вы можете написать свой собственный довольно простой эвристический анализ и затем использовать его во время каждой следующей обработки файла.Собранная статистика должна быть сохранена для сохранения эффективности между перезапусками.

В основном интерфейс: 

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

...