Для моего личного проекта я пишу небольшой класс для сжатия и распаковки из довольно неясного формата. У меня есть полная спецификация, но проблема не в этом.
Во-первых, этот «формат» использует набор из 6 различных типов сжатия, а также несжатые блоки байтовых данных. Форматы: RLE, ответвление RLE, где число увеличивается на каждый байт (например, 3, 4, 5, ...), 16-битное RLE, LZ-Copy, обратное LZ-копирование и LZ-Copy Xor ' d с 255. Это не самая чистая из спецификаций, но я тоже ее не проектировал.
Моя подпрограмма сжатия должна принимать массив от 1 до 65535 байтов и (надеюсь) сжимать ее как можно больше. Моя предыдущая попытка просто вычислить, начиная с любого индекса в несжатом потоке, какой из методов сжатия, приведенных выше, обеспечит наилучшее сжатие, а затем сжимает сколько бы байтов этот метод ни сжал до массива сжатых байтов перед повторением из новый «несжатый» индекс, например:
{0,0,0,1,2,3,4}
Алгоритм сначала считал бы, что в начале было три нуля, а затем вывел бы для них кодировку RLE, которую использовала спецификация, а затем, начиная с четвертого элемента, прочитал бы, что увеличивающийся RLE будет покрывать '1,2 , 3,4 'достаточно хорошо и сожми это перед возвращением.
Обобщенная проблема заключается в том, что при попытке найти лучшую спецификацию для использования процедура очень медленна даже для небольших (20-30) байтовых массивов. Может ли кто-нибудь помочь с советами о том, как я могу смотреть на оптимизацию этого, или есть ли какая-либо дополнительная информация, которую я мог бы предоставить, чтобы помочь?