@hirthwork

Тег байтоёбство в блоге hirthwork

hirthwork

В июле в re2j добавили поддержку именованных групп. Я решил протестить его на тех же данных, что в #zhxde. В этот раз с более точным замером времени. Вот результаты:
Для файла размером 1128824 байт:

jni + pcre              — 111ms
com.google.re2j.Pattern — 201ms
java.regex.Pattern      — 886ms

Для файла размером 408739 байт:

jni + pcre              — 13ms
com.google.re2j.Pattern — 40ms
java.regex.Pattern      — 6ms

Какие выводы можно сделать?
1. re2j заявляет что работает с линейной сложностью и это, похоже, примерно выполняется
2. re2j не является серебряной пулей. Т.е. есть случаи, когда java.regex.Pattern его сильно обгоняет
3. Я хуею от результатов java.regex.Pattern. Вот блядь вообще не знаю как объяснить эти результаты. Тем более что регулярка у меня не вот прям сложная, а проверяет, что семь слов встречаются в тексте, а между ними может идти всё что угодно (ну и регистр некоторых символов может варьироваться)
4. jni + pcre неожиданно хорош. С учётом того, что ему нужно сначала целиком скопировать содержимое UTF-16 строки, затем сконвертировать её в UTF-8, а потом прогнать регулярку — это очень неплохой результат.

hirthwork

Что быстрее, два лукапа в таблице, switch на 22 case или «один лукап, один if и один shl»?

hirthwork

посоны, я тут читаю Instruction latencies and throughput for AMD and Intel x86 processors и тут у меня такой вопрос возник, чо реально в плане производительности нет разницы что написать в коде if (i == -1) и что написать if (i < 0)?

hirthwork

вы представить себе не можете, как ранит моё сердце профайлер, когда показывает что while (ptr < end) { switch(*ptr) {...} } съедает 30 процентов времени

hirthwork

Ура! Я вспомнил, что for (i: 1..1000) {... for (j: 1..1000000) ...} работает быстрее чем for(j: 1..1000000) {... for (i: 1..1000) ...} и соптимизячил этот боттлнек!

hirthwork

пацаны, а что быстрее, switch или вызов виртуальной функции?

hirthwork

Решил ускорить одну функцию. Ожидаемый прирост производительности: ≈1%. Фактический прирост производительности: 25%

hirthwork

неожиданно оказалось, то у коллекций col.toArray(new T[0]) работает быстрее чем col.toArray(new T[col.size()]) © http://shipilev.net/blog/20...ays-wisdom-ancients/ вот и верь после этого утилитам для статического анализа кода

hirthwork

Rabbit Hole of Performance Engineering — you cannot finish the dive, you can only stop it

hirthwork

Все любители позадрачивать байтоёбство теперь могут задрочить его до невероятных высот! https://gmplib.org/~tege/x86-timing.pdf

hirthwork

прыщаны, а на какой фс лучше всего хранить /usr/portage? (будем считать, что /usr/portage/disfiles на ext4) а то с холодного старта ext4 крайне неторопливо по портэжу лазает

hirthwork

программач, я тут подумал, а если у lock-free очереди только один читатель, то ведь её проще сделать поверх lock-free стека, который при запросе элемента будет обнулять head, и инвертировать односвязный список. я ведь не ошибаюсь?

hirthwork

нужна функция которая работает очень быстро, и возвращает текущее время (с точностью до 100мс), будет ли выигрыш по сравнению с gettimeofday() если просто запустить отдельный тред, который будет 100мс спать, а затем дёргать gettimeofday и записывать его в некую шареную переменную, доступную потребителям этого счётчика?

hirthwork

что быстрее префиксный инкремент int'а или его копирование?

Добавить пост

Вы можете выбрать до 10 файлов общим размером не более 10 МБ.
Для форматирования текста используется Markdown.