Человек хочет комбинировать выражения вместо комбинации функций. Зачем? Хз. На FPS это влияет отрицательно, на сложность отладки и разработки тоже, из положительного только "крутость" решения.
Если время парсинга и компиляции не важны почему вы не использовали Roslyn или CodeDom для компиляции c# кода?
По тому что они не работают везде, где может запускается Unity. Моим пользователям не важно время пасинга и биндинга т.к у них все практические кейсы в том что бы запарсить выражение из строки а потом вызывать миллионы раз. Например взять из конфига формулу
скомпилировать в рантайме и потом много раз использовать.
Соотвественно проверять перфоманс на бенчмарке холодного старта не совсем корректно.
Стоило разбить на парсинг + биндинг и вычисление. Ну и мерить один запуск это мелко, стоит сделать 100.000 итераций + замерить сколько мусора будет создано в памяти.
Вы человеку так все бенчмарки поломает :) после компиляции выражений у всех либ разница будет только в скорости паркинга и биндинга, что скорее всего большинство пользователей не интересует.
Btw у меня есть аналогичная либа с полным c# 3.5 синтаксисом и поддержкой AOT для unity
Исследование мира в играх это когда надо выбираться из уютной и удобной базы во внешний мир и открывать новое. А просто исследования, это процесс открытия технологий за время и деньги. Две разные механики. Но это занудство, да, можно было выбросить одну из предложения.
Я не смог найти в русском слово для exploration. И когда рядом research и exploration надо выбирать как это написать что бы не получилось "исследования и исследования".
Ну и конечно в статье про улучшение производительности очень нехватает результатов замеров до и после (и в процессе), понять получилось быстро или медленно (относительно лучших существующих решений) невозможно. О файлах какого размера речь хотя бы идёт? И о каком времени обработки? И что мешает взять существующие библиотеки в проект, где важна производительность?
У каждого разработчика игр свой ответ на этот вопрос. За очень редким исключением большинство выбирают текстовые форматы для хранения игровых конфигов.
Мои ответы: а) один источник правды - сам JSON/YAML/INI/CSV файл б) возможность по-быстрому подправить и перезапустить игру без экспортов в бинарный формат в) возможность моддерам без доп инструментов что-то добавить/убрать/затюнить
Да, есть еще вариант хранить в формате MessagePack, и даже есть парсер который в 2.7х быстрее чем JSON. Но у бинарных форматов есть огромный минус, они плохо диффятся и мержатся в системах контроля версий. Даже без мержей, просто посмотреть что поменялось в бинарном файле невозможно.
Видел тот код. Автор simdjson мыслил другими категориями и понятиями пока недостижимыми для меня. Там весь токенизатор это две инструкции лукапа по таблицам, и никаких стейт машин.
А расскажите пожалуйста, в чём преимущество перед стандартным парсером из System.Text.Json?
Преимущество в том, что такой парсер работает в любой версии Unity и как и .NET. Этот парсер часть генерируемого кода тулы для чтения игровых конфигов. Мне неизвестно, где незвестно где этот код будет запущен. Оно плавно деградирует (через #if) до самых плохих условий исполнения и работает везде. В то время как System.Text.Json хочет свои зависимости и правильный рантайм со Span и ReadOnlySequence.
Есть ли бенчмарки?
Только что сделал 10mb JSON на .NET Framework 4.7.1 (Core могут быть чуть другие результаты):
| Method | Mean | Error | StdDev | Ratio | RatioSD | Gen0 | Gen1 | Gen2 | Allocated | Alloc Ratio |
|------------------------------- |---------:|---------:|---------:|------:|--------:|----------:|---------:|---------:|----------:|------------:|
| JsonFormatter | 74.45 ms | 1.163 ms | 1.384 ms | 1.03 | 0.03 | 3714.2857 | 142.8571 | - | 23.82 MB | 1.05 |
| SystemTextJsonFormatter | 72.40 ms | 0.607 ms | 0.538 ms | 1.00 | 0.00 | 3714.2857 | - | - | 22.64 MB | 1.00 |
| JsonFormatterWithStringPooling | 65.76 ms | 0.743 ms | 0.695 ms | 0.91 | 0.01 | 2500.0000 | 750.0000 | 250.0000 | 14.98 MB | 0.66 |
Кажется, что даже десятки мегабайт, прочитанные один раз (речь ведь про настройки) не должны стать проблемой
Вот это только токенизация 10Mb JSON т.е. "Read() + reader.GetString()/GetInt()", а еще сколько занимает создание объектов и складывание в них. Представьте теперь вместо моего современного PC процессора мобильный процессор который троттлится от жары.
Данные из простых типов (например, характеристики персонажа) гораздо удобнее хранить в обычной экселевской таблице (или в каком-то удобном вам текстовом формате) и уже оттуда генерить в движок.
WebSockets делают ваши подписки GraphQL сохраняющими состояние
Если у вас заголовок аутентификации это состояние, то остальные запросы идут без него? А если другие запросы призадумаются и пользователь выйдет пока они выполняются, то они прервутся? Нет же? Значит у вас везде "состояние".
WS в качестве потока событий вообще никак не отличается от SSE. Одни и те же преимущества, те же проблемы с аутентификацией (нет возможности задать заголовки).
Но у WS есть per-message-deflate, а у SSE из коробки ничего.
WebSockets заставляют браузер откатиться к HTTP/1.1
RFC 8441 уже 6 лет как в node.js, да и в отстальных серверах оно есть
WebSockets вызывают проблемы безопасности, раскрывая токены аутентификации клиенту
Дак не раскрывайте. Кукисы, одноразовые токены итд.
WebSockets позволяют двунаправленную связь
Плюс же, а не минус. Выработайте протокол взаимодействия по вашему каналу, и закрывайте соеднинение при его нарушении.
Да, с автоматическим рекконектом и разбиением ответа на кусочки от браузера.
Человек хочет комбинировать выражения вместо комбинации функций. Зачем? Хз. На FPS это влияет отрицательно, на сложность отладки и разработки тоже, из положительного только "крутость" решения.
По тому что они не работают везде, где может запускается Unity. Моим пользователям не важно время пасинга и биндинга т.к у них все практические кейсы в том что бы запарсить выражение из строки а потом вызывать миллионы раз. Например взять из конфига формулу
скомпилировать в рантайме и потом много раз использовать.
Соотвественно проверять перфоманс на бенчмарке холодного старта не совсем корректно.
Стоило разбить на парсинг + биндинг и вычисление. Ну и мерить один запуск это мелко, стоит сделать 100.000 итераций + замерить сколько мусора будет создано в памяти.
Вы человеку так все бенчмарки поломает :) после компиляции выражений у всех либ разница будет только в скорости паркинга и биндинга, что скорее всего большинство пользователей не интересует.
Btw у меня есть аналогичная либа с полным c# 3.5 синтаксисом и поддержкой AOT для unity
Оптимизация это процесс достижения оптимальных параметров под задачу, если задача получить половину ФПС, то все успешно выполнено. КО
Land RIder: Начало
Исследование мира в играх это когда надо выбираться из уютной и удобной базы во внешний мир и открывать новое. А просто исследования, это процесс открытия технологий за время и деньги. Две разные механики. Но это занудство, да, можно было выбросить одну из предложения.
Я не смог найти в русском слово для exploration. И когда рядом research и exploration надо выбирать как это написать что бы не получилось "исследования и исследования".
Второй ReadOnlySequence<T> который набор сегментов с ссылкой на Next. А можете показать код первого для изучения, если это не секрет.
В комментарии https://habr.com/ru/articles/828502/comments/#comment_27035122 есть ответы на все эти вопросы и бенчмарк.
У каждого разработчика игр свой ответ на этот вопрос. За очень редким исключением большинство выбирают текстовые форматы для хранения игровых конфигов.
Мои ответы:
а) один источник правды - сам JSON/YAML/INI/CSV файл
б) возможность по-быстрому подправить и перезапустить игру без экспортов в бинарный формат
в) возможность моддерам без доп инструментов что-то добавить/убрать/затюнить
Да, есть еще вариант хранить в формате MessagePack, и даже есть парсер который в 2.7х быстрее чем JSON. Но у бинарных форматов есть огромный минус, они плохо диффятся и мержатся в системах контроля версий. Даже без мержей, просто посмотреть что поменялось в бинарном файле невозможно.
Видел тот код. Автор simdjson мыслил другими категориями и понятиями пока недостижимыми для меня. Там весь токенизатор это две инструкции лукапа по таблицам, и никаких стейт машин.
Преимущество в том, что такой парсер работает в любой версии Unity и как и .NET. Этот парсер часть генерируемого кода тулы для чтения игровых конфигов. Мне неизвестно, где незвестно где этот код будет запущен. Оно плавно деградирует (через #if) до самых плохих условий исполнения и работает везде. В то время как System.Text.Json хочет свои зависимости и правильный рантайм со Span и ReadOnlySequence.
Только что сделал 10mb JSON на .NET Framework 4.7.1 (Core могут быть чуть другие результаты):
Вот это только токенизация 10Mb JSON т.е. "Read() + reader.GetString()/GetInt()", а еще сколько занимает создание объектов и складывание в них. Представьте теперь вместо моего современного PC процессора мобильный процессор который троттлится от жары.
Или в специализированном инструменте для этого - статичной БД. https://assetstore.unity.com/packages/tools/visual-scripting/charon-game-data-editor-95117
Зато видно, что перевод не ИИ и гугл-транслейтом :)
Закон ИМХО заточен против хитрожопых, которые захотят создать антиутопию на основе ИИ. Штрафы это палка которая заставит их передумать.
Ребята так и не переименовали студию из raspiL - Lipsar в нечто непаливное :D
тем более что там даже Windows не надо, .NET [Core] можно хостить хоть под линуксом, хоть под макОС.
Если у вас заголовок аутентификации это состояние, то остальные запросы идут без него? А если другие запросы призадумаются и пользователь выйдет пока они выполняются, то они прервутся? Нет же? Значит у вас везде "состояние".
WS в качестве потока событий вообще никак не отличается от SSE. Одни и те же преимущества, те же проблемы с аутентификацией (нет возможности задать заголовки).
Но у WS есть per-message-deflate, а у SSE из коробки ничего.
RFC 8441 уже 6 лет как в node.js, да и в отстальных серверах оно есть
Дак не раскрывайте. Кукисы, одноразовые токены итд.
Плюс же, а не минус. Выработайте протокол взаимодействия по вашему каналу, и закрывайте соеднинение при его нарушении.