Abnormal programming
Designing and refactoring
Game development
Comments 39
+9
Буквально вчера был эпизод увеличения производительности в ~72 раза одной кнопкой. Это было delete по вызову логирования, который по некоторым историческим причинам попал внутрь одной функции, вызываемой при численном интегрировании сложной матмодели. Профилировщик, правда, для этого не понадобился, просто нужно помнить что логи — штука медленная, и если пишешь их для отладки, то после себя — удалять, а не комментировать на случай «а вдруг оно опять понадобится». Не понадобится. Зато кто-нибудь другой может залезть в код и сказать «о! логи закоменчены!» и вернуть всё взад.
0
А можно добавить еще один коммент: " логи — штука медленная!"? :)
+1
Почему Microsoft просто не поставили более мощный процессор в приставку?
Ведь разработка нового процессора стоит меньше, чем зарплата программиста.
+24
А ведь именно из-за того мышления мы сейчас получаем лагающие игры даже на новых i9 в связке с 2080.
Код должен быть оптимизирован всегда. А херовый код даже лучший процессор не вытянет.
+22
Я искренне подозреваю что сказанное про процессор было сарказмом, просто его не поняли. Ведь разработка процессора намного дороже чем найти баг в программе.
+1
разработка
Нет, это было сказано полностью серьезно, конечно-же.
+7
walti
Ведь разработка нового процессора стоит меньше, чем зарплата программиста.

walti
разработка
Нет, это было сказано полностью серьезно, конечно-же.

dimonoid
Может имелась ввиду не разработка, а покупка процессора?


Знаете, я уже не уверен, что я имел ввиду. (с) walti
+5
У приставок своя атмосфера. В отличие от настольных ПК они не подлежат апгрейду и имеют при этом гораздо более долгий срок жизни. Поэтому в любом случае даже супер-пупер железо на момент выхода приставки (а точнее на момент начала ее разработки) уже через несколько лет успеет устареть и разработчикам придется выкручиваться.

Я помню очень удивлялся, как на PS3 с ее жалкими 512 (кажется) Мб памяти летали игры, которые лагали на ПК с двумя гигами. Сколько ухищрений, оптимизаций и упрощений запихивали разработчики туда.
0
Там ещё столько же видеопамяти, а когда очень надо — что-то можно и в видеопамять сложить… прям как tor на машинках 30-летней давности, да…
0
Кеширование — вообще непростая штука и я чисто видел случаи, где пытаясь сделать лучше только убивали производительность именно тем, что «а давайте мы поставим кеширование».
Ошибки такого рода больше свойственны начинающим, кто плохо понимает механику работы и кто не умеет пользоваться инструментами замера производительности.
0
Сильно увеличил размер индекса в чей-то реализации хэш-таблицы. На малом кол-ве элементов хэш работал нормально, а на миллионах вставал колом.
+1

Исправил регулярное выражение, тем самым увеличив скорость комплиляции шаблонов Laravel в 40 раз :)

0
Тоже была подобная проблема с регулярками, только для проверки на то, что строка является ссылкой(целиком). Правда решил не исправлением большой регулярки, а проверкой каждой части ссылки своей регуляркой.
+1

Лет 5 назад столкнулся с интересной проблемой catastrophic backtracing в regular expressions (статья не моя, просто пример). Это когда визуально вроде всё нормально, и оно даже работает. Но с увеличением длины строки производительность гасится весьма нелинейно. Патч в 1-2 символа. С тех пор стал писать их куда внимательнее :)

0
Ускорил файловый кэш (на секундочку, сам кэш призван ускорять) в бородатом симфони 1.2 в 3-10 раз
0

Нужно просто разрабатывать на процессоре (пусть даже i9), но на пониженной частоте строго 2-3ghz, а запускать потребителю — на нормальных 4-5ghz. Вот и весь секрет скорости.

+1
Не разрабатывать, а отлаживать (тестировать). И желательно частоту вообще где-то в 1ГГц загнать, но заставить ПО использовать все доступные ядра, чтобы ещё и многопоточные ошибки проявлялись почаще.
0

Кто-то закомментировал кеширование при формировании списка товаров для отладки и забыл вернуть. Исправил это спустя год-полтора :-)

+3

Добавил в таблицу индекс, отчёт стал готовиться за 40 секунд вместо 40 минут.

-1

Только что заменил селект из сабселекта из сабселекта, сбор айдишников в цикле по выбранным в первом селекте записям, селект с условием where id in (17000 айдишников собранных в цикле) на селект с одним простым джойном, запрос стал выполняться 15 миллисекунд вместо 35 секунд. Оптимизация в 2000 раз, однако. Апгрейженный из-за перегрузки сервер теперь загружен процентов на 5%, хоть майнер запускай.

0
У нас один добрый человек выводил hp-bar'ы над юнитами, используя stencil bufffer, очищая его каждый раз перед отрисовкой нового bar'a. Простая замена на scirrors дала более чем двукратный прирост fps:)
+1
>> Добавил в таблицу индекс…

Удалил сложный индекс в таблице-снизил число блокировок и увеличил производительность БД
0
Одни из самых противных ошибок это те которые не приводят напрямую к вылету, но зато грузят процессор.
+2
Ой да ладно, эта байка пересказывается с абсолютно рандомными именами, фамилиями и местами событий.
0
Но вот про котельщика я ее не слышал, причем на историю про котельщика автор оригинала ссылается как на устойчивую единицу рассказа.
+1
А я про Капицу не слышал, зато слышал про инженера Уатта и автомеханика (это два разных варианта).
0
Ну, кто что читал. Но идея про Капицу мне для легенды больше нравится.
0
А я читал версию, что на атомной станции были проблемы. Мелкие, но неприятные, и это атомная станция. И как старенький профессор пометил карандашом проблемную трубу, оказался тысячу раз прав, и в конце рассказа объяснял, что взял деньги не за время, потраченное на решение проблемы, а за знание, что и где смотреть
P.S. Читал давно, помню только общий сюжет и найти сходу не смог :(
0
А про забытые в первом контуре ключи и даже фуфайки, к сожалению, не шутки (с мертвого форума):
— А откуда вообще мусор то? Ну поменяли задвижку ну и что?
(случайно забытые гаечные ключи, болты-гайки, ставшие «лишними» я в расчет не беру).
— Так дело в том, что чаще всего именно ключи, гайки и т.д. оттуда и выносятся. Это что, бывало вылавливали фуфайки на фильтрах РГК — почти вход в активную зону.
— Не, это, конечно, мусор, но я думал что такой мусор (болты, ключи) исключен в принципе.Я понимаю что моя наивность не знает границ
0
Частый пробег по одному полю из массива структур тормозил. Вынесение значения этого поля из структур в отдельный массив решило вопрос. (оказалось за годы структуры разрослись и начались промахи кэша...)
Only logged in users are able to leave comments. , please.