Две правки дают 1,8 раза, и одна из них — две строки
Сделано и подтвердилось. Обе правки в дереве (ветка work/skorost, коммиты c903983 и 2854d2b). Замер после: 1,77 раза геометрическим средним, 4,50 на арифметике — предсказание сошлось почти в точку. Вклад по отдельности: флаг сборки 1,14, отметка типа ещё 1,55. Разбор — в type-inference-answers-with-a-node-mark.
Две поправки к прикидкам ниже:
- вторая правка уложилась в нижнюю границу оценки: 150–250 строк ожидалось, ушло около 100 в свидетеле (плюс столько же в копии на самом flang). Причина в том, что проход отметок на дереве в компиляторе уже был, и типы узлов легли туда же, куда до них легла доказанная непустота;
- сборка с
-fltoна большом файле стала БЫСТРЕЕ вдвое, а не медленнее вдвое, как здесь написано ниже. Разбор — в lto-speeds-up-the-build-too.
Ниже — исходное разложение «что чинить первым», как оно было записано до работы.
| правка | объём | выигрыш |
|---|---|---|
флаг оптимизации -flto в порождаемом Makefile | 2 строки | 1,03–1,60× |
| не печатать проверку тега там, где тип уже доказан | 150–250 строк | ещё 1,09–3,15× |
| вместе | 1,8× среднее, до 4,95× на арифметике |
Про вторую оценку стоит сказать отдельно. Сначала она была 60 строк. Автор поднял её до 150–250, разобравшись: проверка типов не отдаёт типы узлов вовсе. То есть сначала надо научить её это делать, и только потом можно не печатать лишнюю проверку.
Это правильное поведение: оценка, выросшая вчетверо после разбора, полезнее красивой оценки, в которую не заглядывали. Ср. a-measured-zero-is-valuable.
Что не входит в этот список и почему. Убирать счётчики шагов не надо — они внутри разброса прибора (provability-costs-2-5-percent). Сторож объявленной меры стоит дорого, но касается 66 функций из 2799.
Отдельно и крупно — память. Кубический рост (arena-never-releases) — это уже не правка, а работа, и она важнее скорости: программа, съевшая 178 ГиБ, не медленная, она просто не работает.
Связано: slower-than-python-by-1-4, provability-costs-2-5-percent, arena-never-releases