Движок la2

[Alay]

Смысл тонкой оптимизации такого кода если он выполняется редко и не крутится в цикле?

а тогда смысл в его поддержке и тестировании если его можно написать 1 раз и забыть ибо работа ведется только над 1 клиентом и переход на другие не планируется
понятно что когда у нас 1000+ зависимостей то такой подход не допустим, но по мне так в данном случае - говнокод будет лучшим решением.

[flopix]

Тогда вы рискуете надолго застрять на этапе продумывания архитектуры приложения.

[Camelion]

Код:

private static void Main()
        {
            var sw = new Stopwatch();
            for (var i = 0; i < 20; i++)
            {
                sw.Restart();
                var result = Appearance.CheckAppearence(Appearance.BaseRace.Ethria, Appearance.BaseSex.Female, 183, 1, 0, 0);
                sw.Stop();
                Console.WriteLine($"Тест моего говнокода. Прогон {i + 1}й занял {sw.ElapsedNanoSeconds()} наносекунд. Результат {result}");
            }
            for (var i = 0; i < 20; i++)
            {
                sw.Restart();
                var result = Appearance.CheckAppearenceV2(Appearance.BaseRace.Ethria, Appearance.BaseSex.Female, 183, 1, 0, 0);
                sw.Stop();
                Console.WriteLine($"Тест красивой обертки. Прогон {i + 1}й занял {sw.ElapsedNanoSeconds()} наносекунд. Результат {result}");
            }
            Console.ReadLine();
        }

На первый прогон не обращать внимание - трансляция Jit'ом.
Понятно что цифры не существенные. но все же. а так как win - не система реального времени - более точные цифры мы не получим

Извини, но таким способом можно мерять, сколько попугаев в удаве, но не продакшн код. Хоть бы прогон показал где нет времени выполнения 0нс. И почему во втором варианте такой разброс дикий в разные стороны?

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

Дальше, попробуем посмотреть на среднее время выполнения. Жаль что вы его не посчитали, но допустим Ваш код быстрее в три условных раза. Означает ли это что создание персонажа работает в три раза быстрее? Абсолютно нет если считать по вашим чиселкам то рпс возрастет в 3-5 раз, но на самом деле хорошо было бы если при такой оптимизации он изменился бы на +0.5%. Соответственно был оптимизирован абсолютно левый участок кода, и вы так и не дали нам нормальные чиселки. Посчитайте полный профит от вашей оптимизации. Запустите в цикле отправку пакета создания на ваш сервер, дождитесь, когда ваш сервер дал ответ, и увеличьте счётчик на единицу. Запустите тест на несколько минут. Потом разделите количество ответов на количество секунд которое работал тест. Так вы узнаете сколько запросов может обслужить ваш сервер в секунду. Если и в этом случае ваш усложнённый вариант реализации все еще значительно уделывает предложенный ранее более простой вариант. Вы молодец закажите пиццу и пивас чтоб это отметить. Если же дифф между вариантами около нуля - не занимайтесь херней и оставьте вариант который будет более прост в прочтении другим программистом.

[Gaikotsu]

Действительно, зачем проверять входные данные от пользователя?

Перефразируя всем известную фразу:

Есть два типа людей: которые проверяют входные данные и которые уже проверяют входные данные.

[n3k0nation]

Gaikotsu,

или так

[Alay]

Gaikotsu,

или так

Честно говоря даже не понимаю к чему это все?...
Если в мой адрес то учтите что сервер разрабатывается с нуля на .net и с позицией - не доверять client'у я полностью солидарен.

[n3k0nation]

Alay, а о Вас речь и не шла. На том же гитхабе достаточно проектов, где авторы слепо верят, что схема протокола и данных - будет строго соблюдена, либо делают верификацию на уровне - как на выложенной мной пикче. Можно даже далеко не ходить и посмотреть в l2j-server.

Запустите в цикле отправку пакета создания

Так вы узнаете сколько запросов может обслужить ваш сервер в секунду.

Это уже по большей части счет производительности network input/output, как со стороны сервера, так и со стороны клиента. Ибо читать и писать в сокет, даже localhost, будет медленее, чем выполнится тот самый код (вместе взятый, да), в особенности, при рабочем JIT'е, за исключением запроса в базу о создании персонажа (если он конечно же не кидается в какой-нибудь мемори пул отложенных запросов).
В любом случае, я согласен, что глупо мерять производительность какого-то мелкого участка кода, который еще и не критичен к скорости работы. Преждевременная оптимизация во все поля.

UPD: тут уж скорее нужно запускать на самом сервере, в цикле, выполнение точки входа пакета и считать время отработки с помощью остановок на safe point'ах виртуальной машины. Точность конечно страдает, из-за того, что виртуалка сама ставит safe point'ы, но всяко лучше, чем мерять время работы сети

а тогда смысл в его поддержке и тестировании если его можно написать 1 раз и забыть ибо работа ведется только над 1 клиентом и переход на другие не планируется

И на выходе Вы получите очень трудноподдерживаемого монстра (а скорее всего вообще неподдерживаемого), где для каких-либо изменений надо будет лезть и править хардкод. Очень сомнительный результат сокращения времязатрат (что в последствии выльется в большие затраты времени на перепил), против написания 10-ти строчек кода, которые будут заниматься десериализацией данных из xml/json/подставить_понравившийся_формат.

[Alay]

Alay, а о Вас речь и не шла. На том же гитхабе достаточно проектов, где авторы слепо верят, что схема протокола и данных - будет строго соблюдена, либо делают верификацию на уровне - как на выложенной мной пикче. Можно даже далеко не ходить и посмотреть в l2j-server.




Это уже по большей части счет производительности network input/output, как со стороны сервера, так и со стороны клиента. Ибо читать и писать в сокет, даже localhost, будет медленее, чем выполнится тот самый код (вместе взятый, да), в особенности, при рабочем JIT'е, за исключением запроса в базу о создании персонажа (если он конечно же не кидается в какой-нибудь мемори пул отложенных запросов).
В любом случае, я согласен, что глупо мерять производительность какого-то мелкого участка кода, который еще и не критичен к скорости работы. Преждевременная оптимизация во все поля.

Вы будете удивлены но было принято решение отказаться от использования баз данных. Все данные хранятся в оперативной памяти.
При деинициализации данные приложения(персонажи, предметы и дт тп) сохраняются на жесткий диск как зашифрованные файлы, с собственной сериализацией, если ее можно так назвать - по сути трансляция памяти в поток и сохранения на диске состояние объектов.
и соответственно при инициализации все это дело восстанавливается.
отдельном потоке происходит runtime сохранение данных на случай краша или иных непредвиденных ситуаций.
На первый взгляд очень сомнительное решение, но в нем тоже есть свои плюсы, особенно если учесть что Озу сейчас дешовая и ее много. Чувствую потом намучаемся связывать сервер с сайтом и придется разрабатывать с нуля еще и обвязку.

[n3k0nation]

Alay, я конечно не знаю всех подробностей такого выбора и решения, но как по мне - проще не изобретать велосипед и взять какое-нибудь NoSQL-решение (раз уж Вы не хотите тащить релляционность):

1. Все они умеют держать данные именно в памяти, с персистентом на диск.
   
2. Целостность данных.
   
3. Атомарность.
   
4. Поддержка изменения структуры объектов.
   
5. ???
   
6. Profit!
   

Либо, на крайний случай, взять какие-нибудь кеши с поддержкой персистентности (ehcache, memcache и другие).

[flopix]

Вы будете удивлены но было принято решение отказаться от использования баз данных. Все данные хранятся в оперативной памяти.

Хранятся в виде уже инициализированных объектов типа персонаж, предмет монстр и т.п. или каких то списков данных?