на самом деле в с# структуры ОБЯЗАНЫ быть унаследованы от класса.
Явный признак - наличие базовых .GetType() / .ToString() / etc у всяких енумов (которые наследуются от Enum, которые наследуется от ValueType, которые наследуется от Object, который содержит эти методы). И именно потому что они УЖЕ ОБЯЗАНЫ наследовать класс - нельзя унаследовать структуру от произвольного класса. Т.е. то что пользователь не может унаследовать структуру от класса НЕ ОЗНАЧАЕТ что на самом деле структура не наследует класс. Ключевое слово struct фактически и означает наследование от ValueType.
Плюс ко всему, ValueType - вообще исключительный случай как для компилятора, так и для CLR. Фактически, наследование от ValueType говорит что это объект фиксированного размера, потому его можно засунуть в кучу.
Дмитрий:
Int32, как и прочие примитивные типы - структуры, которые наследуются от ValueType. ValueType в свою очередь уже наследует Object. В рантайме все что не наследуется от ValueType попадает в кучу (тут уже в зависимости от размера - LOH или SOH), все остальное - в стек.
так сложность задач "находить на фотке лицо" и "находить на фотке какие-то произвольные объекты" отличается на порядок. определения лица на фотке вообще стандартная задача. Даже в самом базовом туториале по опенсв был пример с определением лица по фоткам + есть готовые либы (типа опенфейса) + есть готовые сервисы от майкрософта/гугла/етц.
хм.. судя по тексту ошибки - я бы сказал что проблема с хедером (разница между стандратным deflate и gzip в том, что последний добавляет дополнительно свой хедер). Первых 3 байта должны быть 0x1f 0x8b 0x08
уф... то неловкое чуство когда никогда не читал Троелсена... =)
с банального и очевидного - рихтер "CLR via c#". От корки до корки. Ее все советуют, и она действительно весьма хороша. Причем перечитывать нужно несколько раз с перерывом на практику.
если пойти глубже - Chris Farrell and Nick Harrison "Under the Hood of .NET Memory management". Как возможная замена - Sasha Goldshtein with Dima Zurbalev and Ido Flatow "Pro .NET Performance". Но последняя у меня самого висит в очереди на прочтение, хотя выглядит достаточно интересно.
если еще глубже - Serge Lidin "Expert .NET 2.0IL Assebmler" вкупе с 3ей секцией Common Language Infrastucture (CIL Instruction Set). Собственно этого будет уже достаточно чтоб в купе с каким-то ANTLR попробовать по фану написать свой собственный язык под .нет.
ну и вообще какие-то общие знания по криптографии/алгоритмам/етц лишними не будет. Без бесполезного заучивания, но с пониманием основных подходов и принципов. А все детали уже все-равно будут гуглиться под конкретную задачу. Увы, никаких книг конкретных посоветовать не могу.
вот тут у меня небольшая книгопомойка висит, все книги которые я называл - тут валяются
Дмитрий Гавриленко: эм... как я уже писал выше, GZipStream использует алгоритм Deflate. Он кодирует скользящим окном, потому время от времени будет откатываться назад (при составлении словаря для каких-то новых комбинаций слов). Потому переписывать байты которые алгоритм уже вроде как проанализировал - точно плохая идея. Искать такую плавающую багу будет потом крайне весело.
и еще, а зачем результат в мемори стрим обратно писать? почему не сразу в файл?
Дмитрий Гавриленко: может все-же необходимо использовать алгоритм сжатия Deflate, а не определенную дотнетовскую библиотеку?
как вариант - сжимать сразу не весь файл размеров в несколько гигабайт, а делить его на блоки по 20-100Мб, и сжимать каждый блок в отдельный архив. Но в случае с использованием именно GZipStream эту логику прийдеться самому писать.
не совсем понимаю в чем проблема. Если в системе физически не хватает памяти чтоб запустить 2 алгоритма сжатия - надо пересматривать сами алгоритмы сжатия. Как минимум уменьшая степень сжатия можно очень заметно влиять на кол-во потребляемой памяти. Но я уверен что есть какие-то модификации алгоритмов с упором на "работаем медленее, но и тратим заметно меньше оперативки". Если памяти хватает, но алгоритм просто занимает "лишние" ресурсы - это не проблема, GC в случае надобности сам все почистит потом.
бтв,
папка весом в ~130Мб (первое что нашел похожее по размерам у себя на диске) со всякими mp3 внутри (которые фактически уже сжатый формат, потому почти не сжимаються архиваторами)
LZMA2, словарь 64Kb, размер слова 32, размер блока 8Мб, 8 потоков, ультра сжатие - тратит порядка 700мб оперативки.
LZMA2, словарь 64Kb, размер слова 32, размер блока 8Мб, 8 потоков, скоростное сжатие - тратит порядка 32мб оперативки.
если это не чисто академическая задача - я бы просто подключил 7z и использовал бы его для сжатия файлов. В репозитории есть куча готовых пакетов + его всегда можно просто через консоль вызывать.
и да, на каждом шаге Collect точно не стоит делать, это крайне тяжелая операция. Особенно Collect(2), который тут будет полезен, но заставит систему перебирать всю занятую память.
Дмитрий Гавриленко: надо смотреть на конкретную пдфку. Пдф сам по себе весьма сложный формат (официальная спецификация с описанием формата порядка 1300 страниц). В себе он может содержать куски зашифрованной информации, картинки в разных форматах етц. Т.е. вполне может оказаться что 90 процентов информации с той пдфки - уже какие-то сжитые бинарные данные. А GZipStream использует код хаффмана для сжатия, который будет крайне плохо работать для бинарных данных.
Я бы предолжил для начала посжимать этот файл ручками используя разные алгоритмы. Тот-же LZMA должен нормально справляться. А потом уже смотреть какой алгоритм лучше всего подходит для задачи.
tnnmi: не совсем так. CLR выделяет фиксированное кол-во памяти для g0 и g1. размер памяти под g2 не ограничен (всм, не ограничен со стороны CLR). Это для SOH. Для LOH выделяеться вообще отдельный сегмент памяти, потому понятие "поколение" для такие обьектов не применимо. Но да, чистка LOH происходит только во время полной чистки (когда мы проверяем g0, g1, g2, LOH).
и да, начиная с 4.5.1 мы можем использу GCSettings.LargeObjectHeapCompactionMode сказать GC что для LOH таки нужно проводить дефрагментацию.
на самом деле в с# структуры ОБЯЗАНЫ быть унаследованы от класса.
Явный признак - наличие базовых .GetType() / .ToString() / etc у всяких енумов (которые наследуются от Enum, которые наследуется от ValueType, которые наследуется от Object, который содержит эти методы). И именно потому что они УЖЕ ОБЯЗАНЫ наследовать класс - нельзя унаследовать структуру от произвольного класса. Т.е. то что пользователь не может унаследовать структуру от класса НЕ ОЗНАЧАЕТ что на самом деле структура не наследует класс. Ключевое слово struct фактически и означает наследование от ValueType.
Плюс ко всему, ValueType - вообще исключительный случай как для компилятора, так и для CLR. Фактически, наследование от ValueType говорит что это объект фиксированного размера, потому его можно засунуть в кучу.