5.3 Продуктивність пакування файлів

Стосовно вимірювання зменшення продуктивності від пакування файлів, то тут, здавалося б, немає нічого складного – беремо неупакований файл, запускаємо його, заміримо час завантаження, записуємо результат на папірці, упаковуємо, запускаємо ще раз, і...

Перший камінь спотикання –що розуміти під "часом завантаження"? Якщо проектування–так воно виконується практично миттєво, і їм можна взагалі зневажити. Моментом часу, починаючи з якогозпрограмоюможна повноцінно працювати? Так це від самої програмиа залежить більше, ніж від його упакування. До того ж, на час завантаження упакованих файлів дуже сильно впливає кількість вільної на момент запуску фізичної опе­ра­тивної пам'яті (неслід плутати з загальним обсягом пам'яті, установленої на машині). Якщо перед запуском упакованого файлу ми завершимо один-двавеликі програмнідодатки-"монстри", то зайнята ними пам'ять виявиться вільною, і зможе безперешкодно використовуватися распаковщиком.Алеякщо віль­ної пам'яті немає, їїприйдеться по крихтахвідривати від інших додатків...

Навіть якщо ми оцінимо зміну часу завантаження (що, до речі, зробити дуже проблематично –серія вимірів на одній і тійсаміймашині, з тим самим набором додатків дає розкид результатів більш ніж на порядок), як вимірювати падіння продуктивності інших додатків? Адже, при недостачі пам'яті Windows у першу чергу рятується від немодифікованих сто­рінок,які немає неоюхідносиізберігати на диску! У результаті пакуваннявиконуваного файламожедещопідвищити продуктивністьроботи самого цього файла, але значно погіршитистанінших, неупакованих додатків.

Тому ніяких конкретних цифр навести не можна.Наближеніоцінки, виконані "на око", показують, що при наявності практично необмеженої кількості оперативної пам'яті втрати продуктивності складають менше10%, але при її недостачі швидкість усіх додатків падає від двох до десяти разів!Вексперименті брали участь файли, що виконуються, MS Word 2000, Visual Studio 6.0, Free Pascal 1.04, IDA Pro 4.17, Adobe Acrobat Reader 3.4, машина з процесором CLERION-300A, оснащена 256 МБ ОЗУ, для імітації недостачі пам'яті її обсяг зменшувався до 64 МБ; використовувалися операційні системи Windows 2000 і Windows 98.

Таким чином, можна зробити такі висновки та рекомендації:

1) Файли,щовиконуються під Windows,краще не пакувати. У крайньому випадку–використовуватидляпакування/розпакування функції операційної системи (LZInit, LZOpenFile, LZRead, LZSeek, LZClose, LZCopy), динамічно розпаковуючи в спеціально виділений буфер тільки ті частини файла, що дійсно потрібні в даний момент для роботи.

2) Динамічні бібліотеки взагалі не слід пакувати, оскільки це веде до дивовижної витрати і фізичної, і віртуальної пам'яті і псує саму концепцію DLL:один модуль–усім процесам.

3) Не слідпрагнутибазувати свій додаток на безлічіDLL, – сторінкивиконуваного файла не вимагають фізичної пам'яті доти, поки до них не відбувається звернень. Томусміливо можнапоміщативесь код програми в один файл.

5.4 Принципи роботи програм-архіваторів

Принцип роботи архіваторів заснований на пошукуу файлі "надлишкової" інформації і наступному її кодуванні з метою одержання мінімального обсягу.

Стискання послідовностей однакових символів – найвідомішийметод архівації файлів. Наприклад, усерединінашого файлу знаходяться послідовності байтів, що часто повторюються. Замість того, щоб зберігати кожен байт, фіксується кількість повторюваних символів і їхня позиція. Наприклад, файл, що буде архівуватися,займає 15 байт і складається з наступних символів:

B B B B B L L L L L A A A A A

або ушістнадцятковійсистемі

42 42 42 42 42 4C 4C 4C 4C 4C 41 41 41 41 41 .

Архіватор може представити цей файл утакомувигляді (шістнадцятковому):

01 05 42 06 05 4C 0A 05 41 .

Це оначає: з першої позиції п'ять разів повторюється символ "B", з позиції 6 п'ять разів повторюється символ "L" і з позиції 11 п'ять разів повторюється символ "A". Для збереження файлу в такій формі буде потрібно всего 9 байт, що на 6 байт менше вихідного.

Описаний метод є простим і дуже ефективним способом стисканняфай­лів. Однак він не забезпечує великої економії обсягу, якщо текст містить невеликукількість послідовностей повторюваних символів.

Більш витончений метод стисканняданих, використовуваний у томучи іншому вигляді практично будь-яким архіватором,–це так званийоптимальний префіксный коді, зокрема, кодування символамизмінної довжини (алгоритм Хаффмана). Кодзмінної довжини дозволяє записувати символи і групи символів, що найбільш часто зустрічаються,усього лише декількома бітами, у той час як рідкі символи і фрази будуть записані більш довгими бітовими рядками. Наприклад, у будь-якому англійському тексті буква E зустрічається частіше, ніж Z, а X і Q відносяться дотих, що найменшзустрічаються. Таким чином, використовуючи спеціальну табли­цю відповідності, можна закодувати кожну букву Е меншим числом біт і використовувати більш довгий код для більш рідких букв.

Популярні архіватори ARJ, PAK, PKZIP працюють на основі алго­рит­му Лемпела-Зіва. Ці архіватори класифікуються як адаптивні словни­ко­ві кодувальники, у яких текстові рядки заміняються покажчиками на іден­тичні їм рядки, що зустрічаються раніше в тексті. Наприклад, усі слова якої-небудь книги можуть бути представлені у вигляді номерів сторінок і номерів рядків деякого словника. Найважливішою відмінною рисою цього алгоритму є використання граматичного розбору попереднього тексту з розбиттям його на фрази, що записуються у словник. Покажчики дозво­ляють зробити посилання на будь-яку фразу у вікні встановленого розміру, що передує поточній фразі. Якщо відповідність знайдена, що текст фрази заміняється покажчиком на свого попереднього двійника.

При архівації, як і при компресуванні, ступінь стискання файлів сильно залежить від формату файлу. Графічні файли типу TIFF і GIF уже заздалегідь скомпресовані (хоча існує різновид формату TIFF і без компресії) і тут навіть найкращий архіватор мало що знайде для пакування. Зовсім інша картина спостерігається при архівації текстових файлів, файлів PostScript, файлів .ВМР і їм подібних.