PDA

Просмотр полной версии : [Вопрос] Как лучше хранить ник игрока?



geneff
15.02.2018, 03:25
Здравствуйте..

У меня появился вопрос, где же лучше хранить ник игрока? В трехмерном массиве pInfo[MAX_PLAYERS][pName]
Или создать отдельную переменную PlayerName[MAX_PLAYERS]

Так как же лучше? -_-

DeimoS
15.02.2018, 07:43
Эмм, разницы существенной нет. Главное записывай его только при коннекте и дальше уже обращайся к переменной, а не вызывай по новой GetPlayerName

geneff
15.02.2018, 12:48
Эмм, разницы существенной нет. Главное записывай его только при коннекте и дальше уже обращайся к переменной, а не вызывай по новой GetPlayerName

Так и делаю, спасибо.

Long-
15.02.2018, 14:25
Эмм, разницы существенной нет. Главное записывай его только при коннекте и дальше уже обращайся к переменной, а не вызывай по новой GetPlayerName

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

DeimoS
15.02.2018, 14:40
Ну в первом варианте двумерный массив, доступ к двумерному массиву будет сложнее.
Где то помню, с VWWV спорили, для ника можно использовать лучше глобальную переменную, юзав обычный одномерный массив.

Это из разряда "обращение к нулевой ячейке оптимизированнее (а значит и быстрее), нежели к отдельной переменной". Можешь тогда и от переменных отказаться, начав пользоваться лишь нулевыми ячейками :pardon: Разница во времени будет, примерно, такая же, как и тут. Так что, как я уже говорил, разницы существенной нет :)
Мы с тобой уже на эту тему говорили в вк как-то)


Немного лирики:
Тут суть ведь не в том, что одна реализация быстрее другой, а в том, насколько разница существенна и может ли более медленный вариант доставить проблем. Специально гнаться за миллисекундами или пытаться сохранить каждый килобайт там, где это вовсе не важно - это пессимизация и этим можно заниматься бесконечно долго, уйдя в какой-нибудь байт-код или создания собственной прошивки для чипа процессора, что стоит на машине, с которой запущен сервер. Всё это, несомненно, может дать прирост к одному из показателей, но стоит ли оно того? :)
Оптимизацией нужно заниматься либо когда есть конкретная проблема, либо когда иной вариант реализации кода, который будет более действенен, лежит на поверхности. А когда ради временного промежутка, который даже меньше одного такта процессора, тратится куча времени на то, чтоб узнать: "а что же быстрее/выше/сильнее?" - это уже что-то из разряда маразма :)

Long-
15.02.2018, 14:47
В какой то теме я видел от тебя сообщения , а-ля: "Пусть даже быстрее на 10 мс, но оно лучше ,почему бы не использовать его? Ведь никаких проигрышей ты не получишься только выгоду.".
Так почему бы и здесь не придержаться твоему высказыванию ?)
И автор сказал как лучше, я - ответил, и могу сказать твоими словами :)

geneff
15.02.2018, 14:50
Спасибо за ответы!

DeimoS
15.02.2018, 15:30
В какой то теме я видел от тебя сообщения , а-ля: "Пусть даже быстрее на 10 мс, но оно лучше ,почему бы не использовать его? Ведь никаких проигрышей ты не получишься только выгоду.".
Так почему бы и здесь не придержаться твоему высказыванию ?)
И автор сказал как лучше, я - ответил, и могу сказать твоими словами :)

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


Во-вторых, как я уже писал, я не настаиваю на том, что нужно делать как я говорю. Я лишь сказал как есть: разница между этими вариантами будет настолько мала, что ей можно пренебречь.
Если верить замерам в этой теме (http://pro-pawn.ru/showthread.php?12821), при одном миллиарде итераций разница между обращением к обычной переменной и обращением к массиву будет равна 65542 тиков или ~65мс. Делим это значение на 1 миллиард и получаем 0,000000065 мс - именно такова будет разница между одним вызовом массива и одним вызовом переменной. Собственно, в нашем случае значение не должно слишком отличаться от сравнения массива и переменной (просто временные затраты на оба действия станут чуть больше), поэтому... Ну продолжать, думаю, нет смысла :smile:


В-третьих, в предыдущем сообщении всё, что написано после слов "немного лирики", не является попыткой убедить автора или тебя не создавать отдельный массив для хранения ника. Хочется - создавайте. Я лишь пытался сказать, что не стоит тратить своё время на попытки оптимизировать то, что в оптимизации не требуется. Не стоит поддаваться больной теме по поводу оптимизации, что развилась сейчас в сообществе. Реализуйте свои идеи, создавая скрипты, а не гонитесь за цифрами в профайлере. Иначе станете очередными скриптерами, что не создают ничего нового, а лишь топчутся на месте, пытаясь друг друга переплюнуть в ненужной оптимизации.


UPD: Вообще многим "аптимизаторам" стоит понять, что во всех тестированиях цифры получаются "пугающе большими" лишь потому, что количество последовательных итераций соответствующее. И не забывать делить результат на то количество итераций, которые делал цикл. А то сделают миллион итераций, получат четырёхзначное число и начинают паниковать, забывая про тот самый миллион итераций.

pawnoholic
15.02.2018, 15:46
Зависит от ситуации, я вот вообще перестал хранить имя игрока в глобальной переменной, когда нужно узнаю его через GetPlayerName и все.

А если по теме, то храни так как тебе удобнее обращаться к нему, но если хранишь все таки в трехмерном массиве, например как твой, pInfo[MAX_PLAYERS][pName], то не указывай размер ячеек в enum как это делают все, это критическая синтаксическая ошибка, функции по типу, sizeof не сможет вычислить ее размер.

Long-
15.02.2018, 16:09
Во-первых, тут речь идёт не о разнице в 10 мс и даже не об одной миллисекунде, а, вероятнее всего, о отрезке времени, который, как я уже выше писал, будет равен меньше, чем одному тику процессора (замеров не делал, но операции простейшие) :smile:


Во-вторых, как я уже писал, я не настаиваю на том, что нужно делать как я говорю. Я лишь сказал как есть: разница между этими вариантами будет настолько мала, что ей можно пренебречь.
Если верить замерам в этой теме (http://pro-pawn.ru/showthread.php?12821), при одном миллиарде итераций разница между обращением к обычной переменной и обращением к массиву будет равна 65542 тиков или ~65мс. Делим это значение на 1 миллиард и получаем 0,000000065 мс - именно такова будет разница между одним вызовом массива и одним вызовом переменной. Собственно, в нашем случае значение не должно слишком отличаться от сравнения массива и переменной (просто временные затраты на оба действия станут чуть больше), поэтому... Ну продолжать, думаю, нет смысла :smile:


В-третьих, в предыдущем сообщении всё, что написано после слов "немного лирики", не является попыткой убедить автора или тебя не создавать отдельный массив для хранения ника. Хочется - создавайте. Я лишь пытался сказать, что не стоит тратить своё время на попытки оптимизировать то, что в оптимизации не требуется. Не стоит поддаваться больной теме по поводу оптимизации, что развилась сейчас в сообществе. Реализуйте свои идеи, создавая скрипты, а не гонитесь за цифрами в профайлере. Иначе станете очередными скриптерами, что не создают ничего нового, а лишь топчутся на месте, пытаясь друг друга переплюнуть в ненужной оптимизации.


UPD: Вообще многим "аптимизаторам" стоит понять, что во всех тестированиях цифры получаются "пугающе большими" лишь потому, что количество последовательных итераций соответствующее. И не забывать делить результат на то количество итераций, которые делал цикл. А то сделают миллион итераций, получат четырёхзначное число и начинают паниковать, забывая про тот самый миллион итераций.

Очень много букф, читать муторно, но да ладно это уже мои прихоти.
А так я тоже никого ничего не заставлял делать, я лишь сказал что лучше использовать отдельный глобальный массив под ники , ибо лучше? хоть на 0,0000000000001 но лучше, верно ? Верно.
Закроем тему, и не будем к ней возвращаться, я сказал то что нужно :)