Вход
Регистрация
Введение
Частью нашей работы является поиск способов улучшить производительность (клиента), и так как в этом направлении всегда есть, куда расти, этот поиск идет постоянно.
Во время разработки Tyrannis мы провели несколько массовых боёв на тестовом сервере (Singularity) с целью сбора сведений о любых проблемах с производительностью путем активного наблюдения за этими масштабными сражениями. По мере приближения запуска Тираниса стало ясно, что производительность клиента в флот-боях оставляет желать лучшего (surprise! прим. пер.). Мы получили отчеты, свидетельствующие об очень высоком расходе памяти на клиенте, а так же информацию о некоторых возможных узких местах в плане скорости работы.
Загрузка ресурсов
Во время масс-теста 15 мая 2010 года, мы обнаружили, что наша система кеширования ресурсов время от времени сообщала о том, что размер используемой памяти - отрицательный. После того, как это происходило, некоторые ресуры никогда не освобождали занимаемую ими память, и клиент продолжал накапливать подобные ресурсы до тех пор, пока не заканчивалась доступная память.
Факт отрицательного использования памяти несколько озадачивал, и, кроме того, не все члены флота сталкивались с подобной проблемой. После того, как мы тщательно проанализировали менеджер ресурсов, мы обнаружили пару проблем.
Оказалось, что менеджер ресурсов назначал неправильный размер текстурам, которые были загружены лишь частично, что приводило к тому, что менеджер ресурсов удерживал слишком много памяти - эта проблема была исправлена вскоре после обнаружения. Мы так же нашли и устранили утечку памяти в модуле, отвечающем за загрузку ресурсов. В это же время во время внутреннего тестирования мы стали замечать, что некоторые объекты из системы моделирования физики не очищались (не освобождались) так, как были бы должны, что так же было исправлено.
Когда мы приступили к масс-тестам 20 мая, мы знали, что мы сделали некоторый прогресс, но не были уверены в том, что проблема отрицательного использования памяти не проявится снова. И уже на ранней стадии тестирования стало понятно, что изменения в менеджере ресурсов не решили эту проблему.
Сразу после старта клиент правильно отображал размер используемых ресурсов. Однако с течением времени что-то приводило к тому, что используемая память становилась отрицательной. После масс-теста мы заметили, что варп к небольшому флоту с только что загруженного клиента воспроизводит эту проблему. Кроме того мы заметили, что одним из кораблей был Tengu, T3 корабль. Большую часть ночи мы ходили по пятам за несчастным пилотом Tengu, и в итоге получили достаточно хорошее подтверждение того, что этот Т3 корабль каким-то образом являлся причиной появления отрицательной памяти, а к полночи мы смогли получить четкую последовательность шагов, воспроизводящую проблему.
Оказалось, что переменная, отвечающая за размер геометрических данных, оставалась не инициализированной, что в итоге приводило к появлению непредсказуемых значений, в том числе отрицательных, в процессе генерации полигональной сетки (меша) для Т3 кораблей. Были сделаны необходимые исправления и следующий тест, проведенный 21 мая, показал, что проблема отрицательных ресурсов была устранена!
До исправления
После исправления
После исправления ошибки с использованием ресурсов мы обнаружили, что перед нами еще непочатый край работы, так как в программе всё еще присутствовали объекты, которые оставались в памяти даже после варпа или дока на станцию.
Гарри Судьба и Протухшие Яйца (переводчик не удержался)
Утечки памяти в Еве всегла сложно отлаживать. Из-за специфики взаимодействия между нашими графическим и физическим движками мы вынужденны использовать циклические ссылки. К тому же, когда вы смотрите на (клиент отображает) какие-либо объекты, вы всегда увеличиваете количество ссылок на них, задерживая объекты в памяти на более долгое время.
На примере Destiny:
Destiny (Судьба) - наша система моделирования физики.
Balls (Яйца) - элементарные объекты в физической системе.
За кулисами мы используем эти "Яйца Судьбы" ("Destiny balls", переводчик опять не удержался) для определения скорости и позиции всех предметов в космосе. Мы связываем соответствующие графические объекты с Яйцами Судьбы и рассчитываем на то, что в процессе удаления Яиц Судьбы все связанные графические ресурсы будут так же высвобожденны. Примером удаления Яйца является уничтожение или отварп корабля.
Во время масс-тестов мы заметили, что не все Яйца Судьбы удалялись так, как ожидалось, и что в памяти оставалось приличное количество Яиц даже не смотря на то, что корабли, представляемые этими Яйцами, давно исчезли (из поля зрения этого клиента - прим. пер.). Эти избыточные Яйца Судьбы существуют только на клиенте и мы обычно называем их Протухшими Яйцами. Очевидно, что присутствие таких объектов, особенно с учетом того, что на них так же завязанны некоторые графические ресурсы, оказывает существенное влияние на объем занимаемой памяти.
Когда вы варпаете в гейт-кемп, корабли с агрессией прогружаются в первую очередь, чтобы вы могли быстрее оценить обстановку. В соответствующем коде загрузки присутствовал баг, который при некоторых условиях приводил к добавлению нескольких копий графических ресурсов. Когда такие корабли исчезали, освобождалась только одна копия ресурсов, а остальные продолжали висеть в памяти. Получалось, что эти дополнительные графические ресурсы указывали на Яйца Судьбы, которые должны были бы исчезнуть вместе с кораблями, что и приводило к появлению Протухших Яиц. Эту ошибку было сложно обнаружить, но, к счастью, очень легко исправить (мораль - циклические ссылки - зло, прим. пер.).
Мы так же изменили алгоритм, который Destiny использует для удаления Яиц Судьбы, и теперь после удаления Яйца очищаются все ссылки на это Яйцо из соответствующих ему графических ресурсов. Первый масс-тест со всеми этими исправлениями был проведен 22 мая, и, как мы и рассчитывали, полученные результаты показали, что Протухшие Яйца больше не появлялись.
Всё эти изменения были включены в патч Tyrannis 1.0.2.
Изменения овервью
Во время тестов на Singularity одно из наиболее частых замечаний от игроков было связанно с тем, что овервью обновляется слишком часто и производит "дерганое" впечатление, а так же то, что окно флота приводит к лагам на клиенте. После расследования мы обнаружили, что изменения в составе/структуре флота приводили к существенно большему количеству апдейтов пользовательского интерфейса, чем требовалось. Каждый раз, когда игрок вступал в или покидал флот, перезагружался простой/плоский список членов флота, перезагружалось овервью, и обновлялись все брекеты и все элементы в списке овервью.
Всё это было обнаруженно буквально за пару дней до запуска Тираниса, и мы уже не хотели бы вносить слишком много изменений. Чтомы действительно изменили, так это перестали обновлять овервью, когда игрок вступал в или покидал ваш флот, и вместо этого просто добавляли или удаляли пилота из овервью (в соответствии с вашими настрояками овервью для членов флота). Это изменение привело к новому багу, когда овервью перестало корректно обновляться (упс), но это было исправленно вскоре после выхода Тираниса. В случае же со списком членов флота мы нашли способ обновлять список в 6-8 раз быстрее и решили оставить это в таком состоянии, так как это было достаточно безопасное изменение, которое, тем не менее, разительно улучшило скорость работы окна флота.
После выхода Тираниса мы продолжили работы над этими проблемами. В патче 1.0.2 мы ввели в действие исправления, которые осуществляли более целенаправленное обновление овервью и бракетов в процессе вступления/выхода игроков из флота. Скорость работы окна флота так же была увеличена за счет добавления/удаления пилота в список вместо обновления всёго списка целиком.
Звездная карта
После открытия карты в первый раз соответствующие графические ресуры после загрузки оставались в памяти, что приводило к некоторому увеличению используемой памяти, но позволяло в дальнейшем открывать карту более быстро.
Выяснилось, что если очищать графические ресурсы карты после её закрытия, можно освободить порядка 80 мб памяти. Соответствующее изменение в коде означает, что теперь открытие карты каждый раз занимает чуть больше времени, так как необходимо загрузить/пересоздать нужные графические ресурсы, но есть и преимущество в том, что закрытая карта не использует дополнительную память.
Обновление старого кода
Мы всё время стараемся улучшить и переработать старый и/или медленный код. Мы уже начали использовать новую схему отрисовки, но так как мы не могли обновить абсолютно всё, некоторые вещи в Еве всё еще рисуются с использованием изначальной схемы.
В частности, пылевые облака, те частицы, которые летают вокруг вашего корабля, когда вы движетесь с обычной скоростью (не в варпе, прим. пер.), были одной из вещей, рисующихся старым способом, который очень сильно нагружал процессор и обладал плохой масштабируемостью. Используя нашу новую систему обработки частиц мы уменьшили время, требуемое на отрисовку пыли, на треть по сравнению со старым способом.
Старая неэффективная система так же использовалась для отрисовки звезды в системе (не фоновых звезд, а солнца с маленькой буквы, прим. пер.), и мы перенесли отрисовку звезд на новую систему. Это еще не окончательное обновление отрисовки звезд - в будущем они получат свой шанс засиять еще ярче.
Хотя эти изменения не такие уж и большие, каждая срезанная миллисекунда увеличивает частоту и обновления кадров, и, в конечном итоге, более плавное и гладкое восприятие Евы.
Дальше - больше!
Работа над улучшением производительности велась всё время с момента выхода Тираниса, и на подходе новые улучшения. Мы заменяем нашу старую математическую библиотеку новой значительно более быстрой версией, да и другие старые подсистемы всё еще в процессе обновления.
Все изменения, упомянутые в этом блоге, относятся только к клиенту, и, таким образом, никак не влияют на возможные лаги на сервере и между сервером и клиентом. Но всё же эти изменения делают процесс игры более стабильным, быстрым и приятным.
Мы хотим сказать спасибо всем тем, кто участвовал в масс-тестах на Сингулярити, и приглашаем всех участвовать в будущих тестах. Мы бы не смогли сделать всё это без участия сообщества, сложившегося на Сингулярити.
CCP Blaze
Сообщение отредактировал Takeshi Ryuu: 09 July 2010 - 14:46
Наверх
