Чтобы добавлять сообщения и комментарии, .

@waterlaz:
waterlaz

p = problem $ do
    x <- newVar
    y <- newVar
    x >| 0
    x <| 10
    y >| 0
    y <| 10
    (x*x + y*y) >| 9
    minimize $ x*x - 2*x*y + 4*x + y*y - 4*y + 4 + 7


*Main > last $ take 1000 $ optimize p
(7.000000322085075,array (1,2) [(1,0.8733208989876261),(2,2.872753373591708)])


ня?

@Balancer:
Balancer

Поиск подстроки в юникодной строке в PHP без учёта регистра через preg_match() с модификаторами "/ui" в 7.5 раз быстрее, чем через mb_stripos(). В одном скрипте тут профилировал, 19.5 тыс. проверок. Так время работы — 0.31 сек. против 2.3 сек :)

@fillest:
fillest

оптимизация логгинга

в многопроцессной вебне в лохматой среде (облакопараша, экономия и т.д.) нужен умеренно-отказоустойчивый логгинг при маленьком стабильном латенси ответа + не сойти с ума + опустим остальные подробности.

write в файл непредсказуем. В благоприятной ситуации происходит просто копирование из одного буфера (юзерспейс) в другой (page cache), но периодически планеты выстраиваются в слово "хуй", и write адски лагает.
см. по теме
blog.empathybox.com
yoshinorimatsunobu.blogspot.ru
epickrram.blogspot.ru

Для сохранения рассудка скипаем бесконечные ковыряния в пекле этих всех кишок и придумываем такой дешёвый метод: заводим отдельный тред и очередь. Операция логгинга сводится к сованию в эту очередь. А тред берёт из очереди и уже аппендит в файл. Через некоторый интервал он закрывает и переименоввывает файл, получается файл с готовой порцией данных, которые уже могут быть консистентно прочитаны отдельными обрабатывалками (тут можно ещё подумать и заменить переименование на flock).

Таким образом, если падает приложение-продюсер, данные уже напиханы в ядро, и оно их дошлёт в диск. Брошенные упавшим на полуслове файлы можно определить по времени создания + таймаут интервала ротации (или наверно даже проще по успешности flock'а).
Если падает разгребалка, данные продолжают спокойно копиться до оживления, периодически отправляясь в диск. Worst-case интервал отправки можно настроить через /proc/sys/vm/dirty_* (и/или осторожно добавить fsync в тред).
Если упадёт система, потеряется worst-case на /proc/sys/vm/dirty_* не успевших уйти в диск данных, что в данном случае терпимо и поправимо уже наворачиванием репликации наружу. Отказ диска — то же самое — рейд -> репликация.
Кончилась память — пох. Кончается диск — узнаём заранее из алертинга и увеличиваем.

Нормулёк? Или кочегарить кафки с хадупами в докерах на месосе, подкинув себе работы ещё на пару лет?

@justonemore:
justonemore

Находим более быстрый DNS сервер с помощью NameBench
optimakomp.ru
howtogeek.com

@NeoTheFox:
NeoTheFox

А вот и вопрос к линуксойдам от меня — есть ли кроме BFQ и низкого свопа другие советы по тому, как улучшить произоводительность на одноядерном процессоре родом из нулевых?

@amrok:
amrok

pbs.twimg.com Вот оно как на графике-то наглядно…

@Balancer:
Balancer

В копилку, чтобы потом снова не сочинять. Как отследить в реальном времени все открытия файлов запущенным nginx'ом:

strace $(PP=$(pgrep nginx); echo $PP | sed 's/\([0-9]*\)/\-p \1/g') -e trace=open

@Balancer:
Balancer

Непонятно. Авиабаза последние пару-тройку недель тормозила. Ну, это понятно — Украина, все дела, онлайн до 350 человек одновременно при старой норме 200, количество хитов 150k в сутки вместо прежних 100k (это не считая десятков обращений к мелочи на показ каждой страницы) и т.п. И поверх всего многие десятки потоков активных поисковых ботов всех мастей.

top'ы/iotop'ы показывали, что основная нагрузка — mysql. Его я понемногу и допиливал/оптимизировал. Однако, хотя прогресс по разгрузке явно был, система всё равно тормозила. А сегодня ночью, проводя глубокое профилирование и переписывание генерации превьюшек (совсем для другого проекта) обнаружил в движке забавный баг — во множестве случаев данные по превьюшке не сохранялись в БД и поэтому при каждом запросе данных параметры читались с диска, а нередко превьюшки перегенерировались даже при наличии их на диске.

Исправил ошибки — и опаньки. Волшебны образом сайт залетал. Не знаю, как к вечеру будет, но сейчас онлайн 250 и всё работает шустро.

Что ещё непонятно — по загрузке машины по top/iotop/etc всё выглядит примерно по-прежнему. iowait не упал, в отчётах munin никаких «провалов» по загрузке. Всё выглядит примерно одинаково как при прежних тормозах, так и сейчас, без тормозов. Удивительное, блин, дело. Походу, кроме глубокого профилирования фиг поймёшь, что на самом деле тормозит...

@akastargazer:
akastargazer

С утра попал в пробку на выезде к мосту. Там встречаются несколько потоков из разных районов города, но моя пробка началась ещё раньше.

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

В общем-то, потери времени мало кого волнуют. Богатая страна.

@waterlaz:
waterlaz

Есть некоторая выпуклая дифференцируемая функция f(x), где x — элемент R^n.
В любой точке x мы можем вычислить случайный вектор g(x) такой, что математическое ожидание g(x) равно градиенту в точке x: M[g(x)] = grad f(x).

xm — минимум функции f.

рассмотрим процесс x_{i+1} = 1/i*g(x_i) + x_i

Вопрос 1: стремится ли вероятность того, что |x_n-xm|<epsilon к единице?

Вопрос 2: тот же вопрос, но f — не дифференцируемая, а M[g(x)] — субградиент f(x)

@Scobar:
Scobar

Обратил внимание, что в жуйке просто НЕРАЕЛЬНОЕ количество одинаковых по смыслу тэгов. Предлагаю их каталогизировать.
Поясню на примере:

Допустим я хочу узнать совета в какой то области, вот открываю я форму создания нового сообщения и что вижу ? куча моих тэгов....

Допустим я не знаю как заставить работать PHP скрипт, какой тэг я поставлю перед постом ?
допустим *PHP
А кто то задаст по сути этот же вопрос, но с тэгом *develop, или же *webdevelop, или же *WEB — как видите вариантов миллион.

Я предлагаю ввести так называемые "коренные" тэги от самого сервера — то есть в форме создания нового сообщения неплохо бы иметь уже набор наиболее распространённых тэгов, который бы всегда ставился первым, а к нему пользователь уже сам добавляет нужные ему.
То есть я из предустановленных тэгов сервера беру тэг *develop и добавляю свой тэг *PHP. ( И так по любой теме и направлениям)
Ведь такой подход значительно упростит навигацию и поиск по ресурсу — не будет повторяющихся постов ,и желающий сможет найти не обсуждалось ли это ранее.

В трэд призываю @SannySanoff и мисье @ugnich

Обсуждаем идею, предлагаем версии универсальных тэгов. Прошу рекомендовать пост

@Aerohead:
Aerohead

Оптимизация по русски: стою в очереди на поручение талона электронной очереди

@chegeware:
chegeware

[25] Levenberg, K., "A Method for the Solution of Certain Problems in Least Squares," Quart. Appl. Math. Vol. 2, pp 164–168, 1944.

[27] Marquardt, D., "An Algorithm for Least-Squares Estimation of Nonlinear Parameters," SIAM J. Appl. Math. Vol. 11, pp 431–441, 1963.

@drdred:
drdred

Как обычно, красота кода и его производительность — антагонисты. Убрал функцию, все распараллелилось, заколосилось. Хотя блин раньше сам за подобные фокусы разрабов по пальцам бил, теперь вот сам попал. Эх, давно не брал я в руки шашек...

@JCD:
JCD

elinux.org

@rion:
rion

realnc.blogspot.co.at
так, на заметку

@Talik:
Talik

просто шикарная заметка: Выступали, разумеется, представители тех самых шарашкиных контор, которые благополучно сливают осваивают 90% маркетинговых бюджетов малого и среднего бизнеса. В аудитории было не более 50 человек. Это были предприниматели, специалисты по PR, маркетологи и рекламщики из небольших компаний. После 10 минут выступления первого лектора вышла первая треть аудитории, после выступления второго – вторая треть. Оставшиеся ждали бесплатные булочки с кофе и с отвлеченным видом изучали пейзаж за окном. целиком тут habrahabr.ru

@rbdc9:
rbdc9

Сергей Рыжков, директор Кроникс+, выдвигал отличную идею: во все сервера (желательно и на колокейшне) ставится звуковуха, маленький динамик и небольшая программа. Которая произносит случайное ругательство при прохождении каждого гигабайта через сетевуху.

Представь — датацентр, темнота, и только негромко матерятся сервера в стойках.

@kamenev:
kamenev

На 8 ядер был 57%, а стал 3% после включения write-back кеша на RAID-контроллере. Выйгрыш в 19 раз. М-да...

@kamenev:
kamenev

rudd-o.com

@kamenev:
kamenev

*nginx *postgreSQL
habrahabr.ru

@NokitaKaze:
NokitaKaze

Сегодня ещё раз убедился, что правильное кеширование это первый шаг для поднятия скорости приложения.
Компонент в Delphi, который отвечает за Mysql неоптимизирован для больших выборок. И на выборках более чем на 250 вхождений он тормозит. Получилось так, что сделать 100 запросов по 13000 вхождений быстрее раз в 100 чем сделать один запрос на 1 300 000 вхождений

@iorlas:
iorlas

en.wikipedia.org
Это же вершина оптимизации!

@NokitaKaze:
NokitaKaze

Есть таблица, содержащая элементы. У элементов есть N текстовых свойств. Свойства неравнозначны, то есть это не список однотипных элементов, а каждое свойство отвечает за свой тип. Часто приходится делать запросы к таблице по всем полям через OR. Раньше таблица была такая:
id, e1, e2, e3, e4, e5, e6...
И запросы выглядели также (`e1` like "blahblah")or(`e2` like "blahblah")or(`e3` like "blahblah")or...

Решил "оптимизировать". Сделал каждое поле как отдельное вхождение в таблицу, и теперь она приняла такой вид:
un_id (прим. ключ), id, name, value

Запросы теперь делаются намного проще — (`value` like "blahblah"), но сама таблица разнеслась в размерах. Раньше в ней было 41190 вхождений, и она весила 6.4МБ. Сейчас 534220 вхождений и 24.3 МБ

Даже не знаю как лучше.

@NokitaKaze:
NokitaKaze

Необходимо было распарсить 1 ГБ русского текста. Первая моя наработка каждое слово подряд спрашивала у БД. Скорость парсинга была 2 килобайта/секунду.
Решил кешировать (засунуть в память) весь имеющийся словарь русского языка, а не дёргать его из БД. Скорость стала 30 килобайт/секунду.
Горжусь кешированием

@stasikos:
stasikos

А вы знаете что логирование серьезно все тормозит? Не забывайте выключать все логи нахер! Я вас предупредил. :)

@lomalkin:
lomalkin

Видимо via #1438943 — перед тем как этот пост мне пришел, мой ответ на сообщение отправлялся (!) 1 минуту и 4 секунды.

@prime:
prime

. Быстрая сортировка на AS 3.0 Товарищ написал сортировку используя шейдеры. По его словом прирост по сравнению со штатными методами почти в 20 раз!!! someideas.ru

@Elemir:
Elemir

Захотелось мне поговорить про Forth. Один из наиболее частых аргументов против Forth'а — невозможность оптимизации на современных полурегистровых машинах (в amd64 16 регистров общего назначения, а в ia64 целых 128!). Вторым аргументом является неизбежность побочных эффектов (работы с стеком). Я попытаюсь объяснить, как отчасти избавится от этих недостатков.
В качестве базы я возьму rx core — ядро RetroForth до 9'ой версий включительно. Низкоуровневых слов в rx core всего 31 штука. В rx core (как и в большинстве классических фортов) используется два стека (первый называется stack, второй — return stack) и хип. Также замечу, что из 31'ого слова только 5 работают с return stack'ом (при этом они не работают с хипом) и только 4 работают с хипом.
Рассмотрим следующее выражение в обратной польской записи «2 3 4 +». Если рассматривать его как работу со стеком, то оно не берёт ничего, и кладёт в стек 2 числа. Т.е. его можно рассматривать как функцию от 0 параметров, возвращающую пару значений. Аналогично форт-выражение «dup *» это функция от 1 параметра с единичным возвратом. Теперь важно заметить, что все стандартные слова, кроме if-семейства и then, можно описать в таком виде (значит и их композицию тоже). Единственным тонким местом является выражение «if бла бла бла then». Если бла бла бла изменяет размер стека, то теряется детерминированность результатирующего слова и его уже не выразить не прибегая к стеку.
Ну и наконец пример. В rx core выражение «dup *» откомпилируется во что-то такое (rx core держит верхушку стека в eax, использует esi как указатель стека):
mov [esi-4], eax
lea esi, [esi-4]
mul dword [esi]
add esi, 4
В оптимизирующем компиляторе же (параметры лежат в eax, ecx, edx, возврат там же):
call dup ( если dup inline, то mov ecx, eax )
imul eax, ecx
P.S. Сразу извиняюсь за корявости

@Balancer:
Balancer

Результаты подбора самого быстрого варианта startWith() и endWith(): balancer.ru
// кросспостинг

@zbx:
zbx

Фрагментированные таблицы MySQL и что крутить для оптимизации 2twi.ru

@skobkin-ru:
skobkin-ru

Жуйк, подскажи в чем разница между этими пакетами?
p php5-memcache — memcache extension module for PHP5
p php5-memcached — memcached extension module for PHP5
И, если знаешь, подскажи какой-нибудь мануальчик по оптимизации LAMP.

@waterlaz:
waterlaz

Есть n-мерный гиперкуб с длиной ребра 1. Множество вершин гиперкуба разделили на два подмножества так, что их выпуклые оболочки не пересекаются. Вопрос: какое минимальное расстояние может быть между выпуклыми оболочками?

@Balancer:
Balancer

Вот, если кому интересно, вкратце об основном нынешнем инструменте оптимизации: balancer.ru
// кросспостинг

@waterlaz:
waterlaz

Занимаясь решением одной оптимизационной задачей, обнаружил, что все методы, полученные мной, могут быть получены относительно простым подходом:
Задача сводится к решению систем линейных неравенств. Выписывается квадратичная функция и набор ограничений такой, что необходимые условия ее минимума при ограничениях совпадают с системой неравенств. Функция минимизируется каким-нибудь бесконечно сходящимся методом.
Подскажите, это на что-то похоже? Чего мне нужно почитать, что-бы стать умнее?

@ivanov:
ivanov

Оптимизация друпала, дабы не забыть: habrahabr.ru В камменты можно накидать ещё ссылок, по желанию.

@Mazdaywik:
Mazdaywik

По материалам предыдущего поста (#903076). Отписавшись от @King-Artur-VII'а, я сокращю поток постов на 28 %, от @King-Artur-VII'а и @Constantiner'а — на 43 %, от @King-Artur-VII'а, @Constantiner'а и @Goren'а — на 55 %. Та же фишка и в оптимизации ПО: найти узкие места и ускорить их выполнение.

@prime:
prime

кто-бы что не говорил, плеер с каждым релизом становится лучше. В новом 10,1,53,64 (в линухе) String.replace() работает так же быстро, даже чуток быстрее, как и String().split().join() . утром проверю на винде.

@JobVK:
JobVK

Оптимизация "мягкого" взыскания долгов — areon.ua

@petav:
petav

Идея, собрать все все в одном месте, специальной терминальной сессии. Все пароли сети, адреса. Столкнулся с проблемой что ни чего этого не знаю. Не удобно управлять