Ускоряем hugo на 20% простым изменением в пакете reflect

MethodByName -- не супер важная операция. Если пишется высокопроизводительный (performance-sensitive) код, этот метод использовать нельзя. Если какие-то приложения написаны с его использованием, это обидно, но это не повод писать новые приложения в таком же стиле. (Ниже будет пример, как можно уйти от MethodByName.)

Вопрос к вашему "патчу": зачем при каждом вызове MethodByName делать сортировку, а затем поиск?

Там нет сортировки как таковой. sort.Search() делает поиск по отсортированным данным. По факту, просто вызывается callback с определённым индексом i. Данные уже отсортированы.

Почему нельзя было сразу сделать сортированный список методов, положить его, куда следует и поддерживать?

Так оно и работает. Слайс всегда отсортирован.

Либо хэш-таблицу? Почему нельзя добавлять метод в сортированный список, индекс или хэш-таблицу при его появлении?

Сейчас в rtype нет хэш-таблицы, но есть отсортированный массив (слайс). Если добавлять мапу, то только если лениво инициализированную, потому что есть шанс, что "метод по имени" не понадобится никогда, а память эта мапа кушать будет. А если делать ленивую инициализацию, то усложнится код, всё равно лишняя память на дополнительный указатель и... да ну, имхо, это не оправдано в данном случае, хотя если бы MethodByName было важной операцией, может и было бы оправдано.

Доступ по индексу к методу уже есть в API. Например, есть возможность самому в мапе хранить маппинг name=>index и потом по индексу получать метод.

Как-то так:

m := make(map[string]int)
for i := 0; i < v.Type().NumMethods(); i++ {
  m[name] = i
}

// Далее:
method := v.Type().Method(m["methodName"])

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

На самом деле, там не так уж плохо всё внутри, а в этом конкретном месте был линейный поиск потому что на практике больше 20 публичных методов бывает довольно редко. А если у вас такой кейс и вы упёрлись в MethodByName, то возвращаемся к началу сообщения: стоит перестать использовать MethodByName.

IntelliJ IDEA: Structural Search & Replace

Если что, структурный поиск и замена так же доступны в том же VS Code (и можно в другие редакторы добавить).

Для Go это делается через gogrep.

Для PHP это делается через phpgrep.

Ничто не припятствует использовать gogrep/phpgrep внутри emacs/vim/чём-либо другом. Причём плюс перечисленных инструментов в том, что они могут быть использованы в терминале напрямую.

WYSIWYG-редактор Хабра — худшее из того, что я видел

В интерфейсе всё ещё доступна кнопка на переход в старый редактор. Уже довольно давно обещают его поддержку отключить, но пока ещё можно в markdown писать.

Я даже не знаю, что буду делать, когда это всё будет невозможно. :(

Видимо, это будет мотивация писать статьи на английском и выкладывать их где-то в другом месте. В WYSIWYG я набирать не буду не потому что на хабре он недостаточно хорош, а потому что мне тот же VS Code (а ранее Emacs) для этого кажется более подходящим. А markdown приятен тем, что можно исходники статьи сохранить и не потерять форматирование.

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

gocorpus: открытый корпус Go кода, поддерживающий запросы

Вот реальный пример где это было полезно:

cmd/compile: detect and optimize slice insertion idiom append(sa, append(sb, sc...)...) · Issue #31592 · golang/go (github.com)

Я сначала даже удивился, что на корпусе было 0 срабатываний, но тесты в gogrep показывают, что матчить такие паттерны он может. Так что делаем выводы, что быстрый insert в слайс если и добавлять, то через внешний generic пакет, а не через распознавание паттерна компилятором.

Хотя это так же может означать, что корпус недостаточно разнородный. Если есть предложения, что ещё добавить - открывайте issue, будем расширять. :)

gocorpus: открытый корпус Go кода, поддерживающий запросы

Кроме "разработчиков компилятора", это так же полезно в следующих случаях:

• Разработка инструментов разработчика (IDE и плагины для редакторов, тулы для рефакторинга).

• Разработка статических анализаторов.

• Попытка выбора между вариантами X и Y, когда вы составляете гайдлайны стиля для своей команды (выбираете более идиоматичное).

• Банальное удовлетворение любопытства.

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

Создаём игру на KPHP с помощью FFI и SDL

А что именно "зачем"? Чтобы лучше понимать, что отвечать, хоть я и не "автор языка". И речь про KPHP или PHP? Может быть, кто-то из команды PHP что-то относительно FFI высказывал и вы на это ссылаетесь? Если так, то поделитесь ссылочкой, интересно ознакомиться.

Далее буду считать, что вы уточнили, "зачем это всё в KPHP?"

Я в статье постарался это затронуть, но если кратко: FFI не ограничивается геймдевом и/или графическими приложениями. Через него, гипотетически, можно использовать некоторые C-библиотеки. Зачем нам "какие-то" C-библиотеки? Чтобы была возможность через них реализовать недостающий функционал KPHP (libgd, например).

Одно из преимуществ FFI: модуль для работы с libgd будет работать и на KPHP, и на PHP. Распространять его можно как composer пакет. А ещё этот модуль не нужно будет вливать в основной репозиторий KPHP (в "ядро" языка).

Создаём игру на KPHP с помощью FFI и SDL

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

Отдохнуть правда этим вечером не получилось. :)

Создаём игру на KPHP с помощью FFI и SDL

Я в репозитории с кодом указал, что ассеты не принадлежат авторам проекта, а лицензия самого кода (MIT) не распространяется на ассеты.

Думаю, стоит добавить конкретики и указать, что ассеты именно из Warcraft II.

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

Но, конечно же, вы правы. Это довольно рискованно было выкладывать такое с юридической точки зрения.

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

Создаём игру на KPHP с помощью FFI и SDL

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

У FFI в KPHP есть свои особенности. Например, есть типы ffi_cdata и ffi_scope, без которых код работать не будет. По ходу повествования я раскидал ещё парочку трюков, которые были необходимы, чтобы игра запускалась и на PHP, и на KPHP.

Создаём игру на KPHP с помощью FFI и SDL

Напоминаю, что у KPHP есть чатик сообщества в телеграме: https://t.me/kphp_chat

Там есть как разработчики самого KPHP, так и пользователи.
Присоединяйтесь. :)

А ещё есть https://github.com/quasilyte/awesome-kphp, который может стать более полным с вашей помощью. Через FFI можно реализовать недостающий функционал, а чтобы о ваших библиотеках было проще узнать остальным пользователям - давайте добавлять все полезняшки в этот индекс.

Заметки KPHP: тестирование и бенчмарки

Мы там даже обсуждаем всякие внутренности KPHP и помогаем тем, у кого возникают проблемы с использованием.

Так что welcome. :)

ВКонтакте снова выкладывает KPHP

Я думаю, вы про https://plugins.jetbrains.com/plugin/9927-deep-assoc-completion ?

Из коробки PhpStorm, кажется, такое не поддерживает.

А кроме автодоплений для tuple и shape типов плагин умеет ещё и другие вещи.

ВКонтакте снова выкладывает KPHP

FAQ.

Q: Что такое "движки"?
A: s/движки/сервисы/ (или "демоны") — сервис сообщений, сервис лайков, etc.

Из статьи:

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

Q: А как происходит обращение к полям из KPHP?
A: По именам, но без динамических выражений.

$this->field // ok
$this->$fieldname // not ok

GCCGO против «стандартной» реализации

Подскажите, были ли оформлены результаты в виде тикетов для gc?

Не особо.

Но если поискать в интернете, автоматическую векторизацию вроде как не хотят добавлять из-за потенциального замедления компиляции.

Новый calling convention уже давно обсуждается и там есть некоторые успехи в этом направлении. Тоже по Go трекеру можно найти.

mid-stack инлайнинг уже работает из коробки. Эвристики инлайнинга вроде тоже несколько раз подкручивали.

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

Статический анализ: baseline файлы vs diff

Добавлю в статью и унесу под спойлер. :)

gogrep: структурный поиск и замена Go кода

Я на eg обращал ранее внимание, но к нему маловато документации и примеров. Выглядит как более простая утилита, чем gogrep, я так понимаю, там нет фильтров по атрибутам и не построить конвейеры. Использовать отдельный файл с before/after выглядит не так удобно для интерактивной команды (хотя расширение могло бы создавать такой файл самостоятельно).

Есть ещё малоизвестный (?) gofmt -r, сравнение с которым было в докладе автора gogrep.

Я не знаю, сделано для Go или нет, но в IDE известной компании есть SSR, который работает для нескольких ЯП.

В ruleguard есть возможность описывать quickfix на основе тех же gogrep шаблонов. Разница в том, что можно хранить правила в отдельном файле, что позволит на сохранении заменять всё, что хочется упрощать автоматически. Вот простой пример:

m.Match(`fmt.Fprint(os.Stdout, $*args)`).Suggest(`fmt.Print($args)`)
m.Match(`fmt.Fprintln(os.Stdout, $*args)`).Suggest(`fmt.Println($args)`)
m.Match(`fmt.Fprintf(os.Stdout, $*args)`).Suggest(`fmt.Printf($args)`)

Находим вызовы Fprintf с аргументов Stdout и заменяем на Print* функции.

Тёмные и светлые стороны работы в Яндекс

Надо обладать определенной смелостью, чтобы от лица компании публично критиковать слова другого человека.

Мне кажется, не обязательно приписывать любое высказывание сотрудника высказыванию от лица компании. Как минимум, этот пост не в блоге Яндекса.

Я не знаю, когда это было добавлено в статью, но сейчас там есть это:

Дисклаймер: написанное ниже является моим личным мнением, официальное мнение компании по данному вопросу мне неизвестно.

Ради мыслительного эксперимента, мы можем поставить себя на место другого. Если некто работает в компании X, ему или ей может быть не очень приятно, если любое высказывание (даже с дисклеймером) могут назвать высказыванием от лица X.

Ищем баги в PHP коде без статических анализаторов

Если кто-то использует VS Code для PHP, то теперь под него есть расширение для удобного использования phpgrep.

Митап: карантин, Go away

Меня только беспокоит, что с какого-то момента переходишь тот порог, когда организация становится более серьёзной и напоминает работу.

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

Динамическая типизация — это не инструмент для разработки. Это чепуха (паршивая)

Если бы в статье не было практически прямых оскорблений и принижения чужой позиции, она была бы менее популярной на хабре?

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

В списке причин минуса к статье нет такого, который описывал бы агрессивность изложения, а ставить за "другое" не хочется. Есть "личная неприязнь к автору", но я же автора как человека не знаю, мне конкретно текст не нравится. :)