Рубрика «оптимизация программ»

Профилирование под Linux с помощью Performance Analyzer

Коллеги, считаю полезным рассказать об удобном и бесплатном профилировщике кода для Linux/Solaris. Он входит в пакет Sun/Oracle Developer Studio [1]. По моему мнению, другие части этой среды разработки несколько бесполезны, но профилировщик, который называется Performance Analyzer, очень удачный. Он прост в использовании, наглядно и удобно устроен анализ результатов. На мой взгляд, профилировщик все еще превосходит многие аналоги под Linux. При наличии этого инструмента использование gprof видится странной прихотью и потерей времени.

Если вы не планируете использовать Performance Analyzer немедленно, то дальше можно не читать. Просто запомните, что такой продукт существует. Если же интересно взглянуть, то добро пожаловать.

Читать полностью »

Здравствуйте. Сегодня хотелось бы поговорить снова про статический анализ. И снова про C++. Только в отличие от PVS-Studio мы будем искать не какие-то ошибки в наших программах (хотя они ищут не только ошибки), а места, которые написаны недостаточно оптимально. И одним из таких мест является выбор контейнера для данных в программе. Если я вас заинтересовал, то добро пожаловать под кат!Читать полностью »

Полное название статьи должно было звучать как «Устойчивая „топологическая“ сортировка графа с циклами за O(|V| + |e| log |e|) по времени и O(|V|) по памяти без рекурсии», но мне сказали что это перебор.
Читать полностью »

Несмотря на рост производительности устройств, веб становится всё более требовательным к памяти и процессору. Правильный рендеринг и умное распределение ресурсов по вкладкам — важная часть решения этой проблемы. Константин Крамлих посвятил своё выступление на конференции «Я Frontend» алгоритмам, которые улучшают производительность и экономят ресурсы как в проекте Chromium, так и в Яндекс.Браузере.

Некоторые из них — например, технологию Hibernate — мы уже разбирали в отдельном посте. Доклад Кости освещает задачу более широко: не только с точки зрения переключения вкладок, но и с учетом методов отрисовки контента, тайлов и слоев страницы.

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

— Меня зовут Костя, я руководитель группы разработки внутренних компонентов в команде Яндекс.Браузера. В Браузере я чуть больше пяти лет, занимался разными вещами: от всего декодирования в браузере, всех HTML5-видео, до отрисовки, рендеринга и других подобных процессов.

Читать полностью »

«Решить парадокс Грея с дельфинами может любой, а ты попробуй сделать это без дельфинов. »

К вопросу о кривых Безье, быстродействии Ардуино и одном интересном сайте, или как я провел выходные - 1

Вообще то планировал я провести выходные несколько по иному, съездить на Copter Huck (не то, чтобы я был фанатом коптеров, просто посмотреть, что молодежь придумывает, потусоваться типа), но старшая сестра была категорически против. Я, конечно, настаивал (то есть пару раз хмыкнул и сказал" Ну может, все-таки… будет прикольно"), но она была неумолима, а когда супруга приняла ее сторону, шансов на поездку не осталось. Ну и ладно, «не очень то и хотелось», зато немного посидел над забавной задачкой из области программирования, которую сам себе придумал, о чем и докладываю.

( Необходимое примечание — имелись в виду предыдущие выходные, вот так всегда — написание программы требует пары часов, написание отчета о ней и за пять дней поездок в общественном транспорте не завершено.)

В одном недавнем посте автор рассматривал задачу ускорения (кроме всего прочего) расчета кривых Безье (КБ) на МК со сравнительно слабыми параметрами. Ну на самом деле эти параметры на уровне среднего мейнфрейма 70х годов, но по нынешним временам считаются явно недостаточными. В результате определенных действий автору удалось несколько ускорить вычисления, на мой взгляд, явно недостаточно, вот и решил написать, как это следует делать в первом приближении. Я прекрасно знаю универсальный рецепт решения проблем с быстродействием — взять МК с частотой повыше или перейти на другое семейство, но я родом из тех времен, когда мы учились обходится тем, что есть, просто потому, что ничего другого не было, от слова совсем. По нынешним временам подход устаревший, но мне показалось, что будет не безынтересен и современным читателям Хабра.
Читать полностью »

Многие программисты не понаслышке знают о том, что программа на языке C и C++ собирается очень долго. Кто-то решает эту проблему, сражаясь на мечах во время сборки, кто-то — походом на кухню «выпить кофе». Это статья для тех, кому это надоело, и он решил, что пора что-то предпринять. В этой статье разобраны различные способы ускорения сборки проекта, а также лечение болезни «поправил один заголовочный файл — пересобралась половина проекта».

Picture 1

Читать полностью »

Микрооптимизации в коде

Как правило, при обсуждении диагностических возможностей PVS-Studio за кадром остаются рекомендации, выдаваемые анализатором по поводу микрооптимизаций Си и Cи++ кода. Конечно, микрооптимизации не так важны, как диагностики выявляющие ошибки, но про них тоже интересно поговорить.
Читать полностью »

Всем известно, что преждевременная оптимизация — это плохо и надо себя одёргивать когда, возникает желание пооптимизировать не вовремя. Однако на практике чаще бывает ситуация когда естественное (и, возможно, интуитивно правильное) желание пооптимизировать подавляется по принципу «если вообще не оптимизировать — это не будет преждевременно». Либо так:

Своевременная оптимизация - 1

На мой взгляд, подобные ситуация возникают потому, что границы понятия «преждевременности» весьма нечёткие и интуитивные, как будто это что-то эмпирическое и неуловимое вроде сочности хруста французской булки.

Хотя в принципе довольно странно оперировать какими-то эмпирическими понятиями по отношению к архитектуре программ, алгоритмам и их оптимизации — поскольку это вполне измеримые вещи. А значит — можно достаточно просто измерить своевременность оптимизации. Об этом и поговорим.
Читать полностью »

Прочтение публикации Упрощаем бинарный поиск в Excel сподвигло на дополнительное усовершенствование функции ВПР по сравнению с приведенным в статье.

Что не было учтено, и что хотелось бы добавить:

Читать полностью »

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

Предыстория

Все началось с того, что я открыл для себя т.н. Double-TRUE VLOOKUP trick (трюк с двойным использованием ВПР и ИСТИНА в 4-м параметре). Развернутое описание алгоритма можно найти в статье Charles Williams «Why 2 VLOOKUPS are better than 1 VLOOKUP» (в конце статьи).

Поняв принцип работы и открыв для себя, что этот подход может быть в тысячи раз быстрее обычного линейного поиска (ВПР с 4-м параметром ЛОЖЬ), я начал продумывать варианты раскрыть его возможности. В ходе реализации получилось несколько годных инструментов для контекстной рекламы, один из которых я еще продолжаю улучшать, и уже посвятил проекту пару статей на Хабре. Чтиво рекомендуется SEO-специалистам и специалистам по контекстной рекламе (сразу оговорюсь, по ссылкам в статьях уже устаревшие версии, последняя версия условно 6.0, ссылки на скачивание всех версий, включая самую свежую, будут в конце этой статьи):
Анализ больших семантических ядер, или «Робот-распознаватель»
Лемматизация в Excel, или «Робот-распознаватель 3.0

Так вот, несмотря на невероятную скорость работы этих файлов (невероятную для Excel), их создание потребовало использования таких же невероятно длинных мегаформул как одной из составляющих работы макросов (в последней из вышеуказанных статей приведен пример — формула на 3215 символов). И всему виной сложный синтаксис функции.
Если набить руку с его использованием, он перестает казаться сложным, но неискушенным пользователям, для которых предназначен такой подход, вряд ли захочется разбираться в нем.

Синтаксис выглядит так: Если(ВПР(искомое; массив;1; ИСТИНА)<искомое;""; ВПР(искомое; массив;n; ИСТИНА))
где n — порядковый номер столбца, из которого мы хотим вернуть значение напротив искомого ключа.
Вместо «ИСТИНА» в 4-м параметре можно использовать «1» для номинального сокращения длины формул, это не меняет их сути.
Если озвучить ход работы формулы, будет нижеследующее:
«Если бинарный поиск ключа по первому столбцу массива возвращает значение, меньшее, чем сам ключ, возвращаем пустую строку. Иначе — возвращаем результат бинарного поиска ключа со смещением n»
Подход используется для того, чтобы не возвращать никаких значений, если искомый ключ в массиве отсутствует, т.к. зачастую, если искомое не найдено — нам не нужно меньшее значение. Так сказать, все или ничего. Вкратце, в этом и есть суть «трюка».

Напомню, на карту поставлен прирост скорости, исчисляющийся трех-четырехзначными числами. Если подходить чисто математически — на массиве в 2^20 строк обычный бинарный поиск будет делать ~10 вычислений, формула выше — около 20, в то время, как линейный поиск — ~500.000, т.е. прирост формулы выше — в 25.000 раз. Если голые цифры не впечатляют, более красноречивое эквивалентное сравнение — 1 секунда против ~7 часов.
На практике прирост не столь существенный (в конце статьи ссылка на статью, где сравнивались разные способы). Это во многом связано с затратами процессорного времени на дополнительные процедуры, которые выполняет программа (например, запись значений в ячейки). НО прирост по-прежнему критически значимый (~4000 раз).

Но одновременно с этим мы имеем сложный, совершенно неюзабельный синтаксис. Не всем смертным дался ВПР, что говорить о комбинациях 2х ВПР с ЕСЛИ.

Вопрос со сложным синтаксисом я решил с помощью VBA — написал UDF (user-defined function, пользовательская функция), которая прячет под капот наши условные конструкции, оставляя нам привычный синтаксис всем известного ВПР.

Код UDF:
Читать полностью »