Упоротая оптимизация.

История произошла совсем недавно: мне нужно было понять почему у нас крашился слабый девайс на загрузке одной конкретной игровой карты, при этом на других он вел себя хорошо. У меня сразу подозрение пало на память, т.к. поведение характерно именно для такого кейса. Проверил логи - действительно память закончилась.

А теперь самое инетерсное, начал разбираться и оказалось, что наш картоделатель посадил по 5к юнитов в домики "за картой", чтобы потом оттуда пускать их по триггеру. А рендер работает таким образом, что ему нужно знать верхнее ограничение по отрисовке количества юнитов. Для нормальной игры это вычислялось по формуле: "берем сумму всех юнитов во всех домиках на карте и умножаем на количество игроков (т.к. в теории каждый игрок может применить какой-нибудь скилл, который сдублирует юнитов, например)". Но если вдруг мы что-то не учли - мы просто не рисуем юнитов и все, что в принципе ок, т.к. когда у тебя 1к юнитов на экране - ты уже не понимаешь где кто, а когда 4к - так и подавно.

Так вот этому коду уже 7 лет и понятное дело, что его никто не трогал все это время, но когда в 2015 году мы писали этот код - юнити мало чего умела нормально рисовать в больших количествах, и мы оптимизировали и микрооптимизировали все что видели.
Так вот мы жили с такой игровой картой уже месяца 3 и только сейчас заметили проблему на девайсе с памятью, хотя у нас вместо того, чтобы рисовать и обрабатывать 4к юнитов максимум (+рендер на 20к), мы вдруг начали обрабатывать 220к и никто этого не заметил... И, наверное, если бы не этот девайс - так бы и пошли в релиз 🙂

А вы все "преждевременная оптимизация, преждевременная оптимизация..." 😂

#story #bug