Фирма пишет управляющий и диагностический софт для станков, которые делают печатные платы и электронные компоненты на них размещают. Станки от небольших, размером с половинку маленькой машинки, до большой комнаты. У таких станков стоит обычный писюк, на котором крутится Винда. Ну а на ней управляющее ПО. Одно из приложение написано на WPF. Первое задание моё - написать сжиматель БД с логами. Логи - многословные XML, в которых много повторяющихся элементов. Чтобы скажем 10 ГБ усохло раз в 10. Ну я использовал стандартный GZipStream - вроде, zip-архивы тоже подобным алгоритмом создаются. Трудность была не только в том, чтобы вспомнить, как с потоками, базами данных и прочим работать, а ещё и чтобы 10 ГБ за раз не утягивать в оперативку - оно минимум 20 ГБ тогда в ней займёт (сами данные, плюс их копируешь, пока обрабатываешь, плюс упакованное хранишь и передаёшь на запись). Т.е. пакетную обработку надо сделать. Ну я написал и протестил пока на 1,5 ГБ БД. В памяти такая бы раза в 2 больше места заняла - т.е. 3. У меня больше 800 МБ потребление не поднималось (судя по графику потребления RAM в Студии). Сейчас протестирую с БД размером ГБ на 5. Но и эти полтора гига у меня ноут минуты 3 обрабатывал. Там хоть и сборщик мусора работает по отработанным пакетам, но всё равно потребление видно, что потихоньку растёт. Если до 2 ГБ на процесс дойдёт, то надо что-то ещё придумывать. Может, размеры пакетов уменьшать. Щас у меня 8к записей (1,5 ГБ) обрабатываются пакетами по 500.

Шеф зачем-то просит сохранять промежуточные результаты в файлах - может, чтобы проверить. Так-то можно всё в памяти делать (в streams), без файлов. Если без сохранения промежуточных результатов в файлы, то можно урезать потребление памяти, я думаю. Шеф сказал, что такое пишется за 1 день, если знаешь, как делать, а я уже вторую неделю. )) Ну, во второй раз я конечно по шаблону гораздо быстрее напишу.