Джошуа Редстоун (Joshua Redstone) пожаловался в листе рассылки Git на некоторые проблемы с производительностью, которые возникли у Facebook на большом репозитории. Они создали синтетический репозиторий и провели тесты.

Тестовый репозиторий
4 млн коммитов, линейная история и около 1,3 млн файлов. Размер папки .git — около 15 ГБ, её упаковали командой repack:

git repack -a -d -f --max-pack-size=10g --depth=100 --window=250

Процесс занял около двух суток на хорошей машине (много памяти, SSD). Размер индексного файла составил 191 МБ.

У меня возникла такая задача: нужно обработать файл с данными. Файл разбит на секции длиной около 1 МБ, каждая из них содержит в упакованном виде примерно 100000 записей.Число записей может меняться от секции к секции и записано в заголовке каждой из них. В процессе обработки секция распаковывается, и каждая запись превращается в 20 целых чисел. Для обработки нужно хранить текущую распакованную секцию и несколько предыдущих (где-то 5-10, но может быть и больше – заранее неизвестно, сколько). Вопрос в том, как выделять память для распаковки секций.

Проект, в рамках которого надо решить задачу, пишется на C# под VS 2008 (использование вставок из других языков категорически не приветствуется), основная система, под которой будет работать готовая программа – Windows 7, 64 bit (по крайней мере, пока). И, как обычно, обрабатывать нужно побыстрее.
Первый вопрос, который возникает – надо ли организовывать пул массивов для распаковки, или можно захватывать массив для каждой новой секции заново. Второй вопрос – какой должна быть структура этого массива, что лучше – работать с линейными массивами в 8 МБ длиной, или разбить массив на куски поменьше и организовать, например, массив массивов. Во втором случае – какой должна быть длина этих кусков.

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

Кроме решения проблемы утечки памяти, многие советы позволят ускорить работу браузера, так что пост будет интересен всем, кто использует Firefox. Практически каждый пункт подходит и для почтового клиента Thunderbird.

А если вам просто понравилась девушка с картинки, то здесь хайрез :)

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

Но можно получить эффективность bzip2, при этом существенно увеличив скорость. Речь идёт об утилите pbzip2 — Parallel BZIP2. В обычном случае при использовании bzip2 задействуется только одно процессорное ядро, в то время как на современных системах их может быть 2, 4, или, например, 8.

Pbzip2 может использовать сразу несколько процессорных ядер, что приводит, по заявлению авторов, к почти линейному увеличению производительности. Сжатые файлы, которые создаёт pbzip2, полностью совместимы с bzip2 1.0.2 и более новыми версиями bzip2 (также есть утилита pigz, которая, в свою очередь, является многопоточной реализацией gzip — спасибо altexxx).

Ниже результат тестирования скорости сжатия участка SQL-файла размером 1000M (dd if=dump.sql of=testfile bs=1M count=1000) на компьютере с двумя процессорами Intel Xeon E5520 (4 ядра, 8 потоков, тактовая частота 2,26 ГГц):



Как видно из результатов тестирования, pbzip2, работающий в 4 потока, приблизительно в 3,6 раз быстрее, чем bzip2, работающий в один поток — что действительно является почти линейным увеличением производительности.

При этом pbzip2, работающий в 16 потоков, оказался медленнее, чем pbzip2, использующий 4 потока — вероятно, из-за скорости выполнения операций ввода/вывода. Также смотрите дополнительные тесты в комментариях (спасибо tristan и bliznezz) — в том числе, с использованием tmpfs-раздела в оперативной памяти.

Используется pbzip2 примерно так же, как и просто bzip2, но есть некоторые дополнительные функции, например вывод прогресса выполнения операции в процентах.

Данный пост является началом серии статей про оптимизацию и улучшение производительности GWT-приложений. Поскольку материала у меня накопилось достаточно много, решил разбить его на 2-3 части.
Приступим к описанию того, что нас ждёт в первой статье.

Введение

Меня до глубины души задело заявление моего коллеги, что использовать исключения — это неправильно. А далее последовала череда объяснений: это медленно, это некрасиво, это неэффективно, это неудобно.