Mike World
07.03.2018, 13:43
а можете объяснить, почему когда в формате упаковываешь строку вот таким образом:
format(str, sizeof(str), !"%s говорит: ", PlayerName);
Выводит цифры вместо букв.
Я правда давно форматирую с помощью static const fmt_str[] (из урока Daniel Cortez, спасибо тебе за это, годные уроки, правда иногда хочется спросить конкретно что то, но и на этом норм)
К примеру, как можно оптимизировать вот это?
if(pData[playerid][pAdmin] == 1)
{
SendClientMessage(playerid, COLOR_GREEN, !"=================== Доступные команды ===================");
SendClientMessage(playerid, COLOR_LGREY, !"Практикант: /a /afk /spec /specoff /slap /mute /unmute /goto /ans /tp");
}
else if(pData[playerid][pAdmin] == 2)
{
SendClientMessage(playerid, COLOR_GREEN, !"=================== Доступные команды ===================");
SendClientMessage(playerid, COLOR_LGREY, !"Практикант: /a /afk /spec /specoff /slap /mute /unmute /goto /ans /tp");
SendClientMessage(playerid, COLOR_LGREY, !"Модератор: /get /gun /kick /check /resguns /spawn /gotoveh /jail /unjail /freeze /unfreeze /hp /offjail /offmute");
}
Я упаковал строки
Хоть форум и откатился на пару дней, унеся с собой всю переписку, но не пропадать же писанине :)
Лол. Раньше и всякой техники не было, но как то же жили, так же и мы не стоим на месте и делаем все для лучшей производительности.
Плохой пример от профика как ты показывать всем новичкам то, что оптимизация не важна.
Где я сказал, что оптимизация не важна? О_о
Не путай оптимизацию с пессимизацией.
Оптимизация - это когда у тебя есть проблемный код и ты пытаешься его сделать лучше с учётом того, что тебе нужно (либо оптимизируя память, либо оптимизируя скорость обработки).
Пессимизация - это когда ты ещё не определил, проблемный ли перед тобой код или нет, но уже пытаешься его оптимизировать. Это схоже с тем, что ты сейчас начнёшь принимать инсулин (ибо вдруг у тебя сахарный диабет, о котором ты не знаешь), вместо того, чтоб обратиться к врачу, обследоваться и только потом начать принимать инсулин, если всё же диабет обнаружится.
Как я уже говорил ранее, от того, что ты оптимизируешь и без того хорошо работающий год, ты ничего не изменишь, так как разница была бы ощутима лишь если бы старый код вызывал дискомфорт при игре.
Почему бы не сделать сразу действительно качественный мод, и не парится и не бояться что вдруг где то он щас крашнется.
Сейчас ты примерно говоришь - "Да ладно, работает и похер".
Что? -_- Я наоборот говорю, что нужно изначально писать качественный код и тогда не будет никаких проблем. Но чтоб начать писать такой код, нужно понимать тонкости языка, а не просто заучить 100 разных вариантов оптимизации, суя их где ни попадя.
И "качественный код" - это не тогда, когда на бенчмарке ты добился максимально хорошего результата, а когда твой код просто не создаёт никаких проблем при игре. Просто потому что такова специфика онлайн игр. От того, что ты ускоришь свой код на 0.10 миллисекунды, не изменится ничего, ибо пинг нивелирует все твои потуги. Да и даже если бы речь шла о сингловой игре, эти доли миллисекунды никак бы не отразились ни на чём, ибо игрок просто не заметит изменений. Изменения заметны лишь при появлении проблем и последующем их исправлении. Такова психология человека, увы.
Так же стоит понимать, что процессорное время в миллион раз дороже памяти. Именно поэтому при оптимизации и написании кода алгоритмам нужно уделять в разы больше внимания.
Я лично привык работать на "все и сразу", если делать, то делать качественно и по максимуму, именно такой и нужно подавать пример.
Это как раз очень плохо, если ты не видишь чувства меры. Оптимизировать можно бесконечно долго. А чтоб таким не заниматься, нужно банально знать возможности той платформы, под которую ты пишешь код, не перегружая эту самую платформу. Большего от тебя и не нужно, ибо, как я уже выше говорил, от того, что раньше твой код обрабатывался за 10 миллисекунд, а теперь за 9.50, не изменится ровным счётом ничего, если до этого (когда код обрабатывался за 10 миллисекунд) пользователь не испытывал никакого дискомфорта.
Да и если ты однажды начнёшь профессионально заниматься программированием, работая в какой-нибудь компании, то там ты с таким подходом станешь лишь головной болью у руководства, ибо вместо результата ты будешь лишь затягивать сроки :)
Блин, кто-то я помню писал совсем иные слова :)
Спор с Nexius'om был, когда ты говорил то, что я писал выше в этом посте, если найду пруфы, кину сюда, щас просто не помню тему, по моему про пикапы нажатия на ALT или нет.
Как буд то совсем другой человек пишет.
Ты просто не можешь понять разницу между оптимизацией и пессимизацией.
Возможно, дело в моей подаче информации. Давай попробую процитировать другого человека, который крайне правильные мысли излагает
...
А вообще есть правило программирования - не пессимизировать, то есть не пытаться оптимизировать то, что оптимизировать не нужно и выигрыш от оптимизации чего будет минимален (а какой будет выигрыш на начальном этапе разработки, как правило, сказать нельзя).
На хостинге есть ресурсы - процессор и память. Можно оптимизовать как по одному параметру, так и по другому. Но оптимизировать сразу оба как правило очень сложно (если возможно). Вот ты смущаешься размеру amx, а тебе это мешает? Это проблема? Стоит вообще смотреть в эту сторону?
Тут и в англоязычном разделе многие предлагают использовать битовые поля и прочие методики сокращения использования памяти. Да, безусловно, памяти от этого используется меньше. А на сколько возрастает использование процессора? Кто ни будь задавался таким вопросом и пытался замерить? Например, архитектура х86 очень старая и у процессора есть оп-коды, которые позволяют прочитать из памяти любой байт (по любому адресу). В более новых архитектурах, например в Itanium, такой возможности нет и из памяти можно прочитать только машинное слово (по скольку архитектура 64 разрядная, то 8 байт) и только по адресу кратному величине этого машинного слова. С одной стороны непонятно, за чем такое ограничение, но если приглядеться, то станет видно, что даже x86 процессоры, если у них просят прочитать байт из памяти по адресу, не кратному машинному слову (4ым или 8и байтам), то делает это намного медленней чем если адрес кратен. И по этой причине современные компиляторы во время оптимизации стараются выравнивать элементы структур по величине машинного слова. По этой причине в С++ sizeof(bool) == 4. Мы тратим на хранение 1 бита информации 4 байта, но мы с этим битом работаем быстро.
Все кричат, что нужно использовать строки по 128 слов, вместо 256, но в англоязычном разделе показали, что скорость возрастает не более чем на 5%. Стоит ли такое оптимизировать, учитывая что во многих случаях это усложнит код?
К чему я это все написал. Прежде чем что либо оптимизировать хорошо бы подумать, для чего это делается и что вы будете ухудшать взамен. Если вы оптимизируете использование памяти, то очень часто будет ухудшаться скорость работы, также как и на оборот. И в обоих случаях будет усложняться код - нужно будет его больше тестировать и больше времени потратить на нахождение ошибок (ведь известно, у одного программиста, количество ошибок в основном пропорционально объему кода, грубо говоря, количество строк).
Можно весь мод уместить спокойно в 16384 байт, я просто не представляю куда больше и на что его можно потратить?Признаки быдлокодерства
И так-же стэк показывает признаки халатности скриптера, и его уровень быдлокодерства.
Сделать систему отображения логов разработки в игре? Или любую другую систему, в которой нужно отобразить много текста?
Помещать текст в сегмент данных, объявляя глобальный массив/используя static? Так этим ты только больше памяти потратишь, ибо вместо стэка, который и так уже занимает свой кусок сегмента данных, ты выделишь новый, подчас такого же размера, как и стэк, ещё больше раздувая сегмент данных.
Вообще, не в обиду, но очень похоже, что ты даже не особо понимаешь принципы работы памяти, а просто повёлся на модную в русскоязычном сегменте сообщества SA-MP фишку оптимизировать всё и вся, видимо, показывая этим свой невероятный скилл, под час даже не понимая, что на самом деле ты делаешь только хуже. Стандартные 16384 байт - это не эталон размера стэка, а просто, фактически, рандомное число, которое разработчик выбрал с расчётом на то, что на многие нужды такого количества памяти хватит. Нет ничего плохого в том, что ты увеличишь стэк. Наоборот, вместо выделения дополнительных 4к ячеек (ну или сколько там понадобится выделить, если вдруг ты не сможешь уместить данные в стэке), ты просто выделишь ещё 100-200 ячеек, дабы все данные уместились в стэк.
Как я говорил выше, лучше сделать сразу качественно, и не бояться что , ой вдруг щас не хватит памяти и крашнет.
Что бы не бояться, достаточно понимать как работает твой код и осознанно его писать. Тогда, не поверишь, в некоторых случаях можно даже пренебрегать оптимизацией, от слова совсем.
Неужели самому не приятно, когда все аккуратно, не боясь, ставить на любой даже нубохостинг, и не бояться.
Ну, если нравится делать двойную работу - пожалуйста, но учить этому новичков как минимум глупо :).
Довольно забавно читать кучу упрёков в свою сторону от человека, который просто не так понимает мой посыл, вкладывая в мои слова свой смысл :)
А мы говорим про кривые алгоритмы? Можно просто написать неоптимизированный алгоритм где будет полный быдлокод, но алгоритм будет работать, а-ля тот же SendMess.
SendMess - это как раз пример кривого алгоритма :)
А вот, например, пикапы домов на кнопку, реализованные через обычный цикл без каких-либо дополнительных условий - это уже неоптимизированный алгоритм, который сам по себе не создаст никаких проблем (ибо для сервера 1000 итераций с IsPlayerInRangeOfPoint - семечки), но вместе с другими неоптимизированными алгоритмами может создать проблем. Хотя, при этом, долгое время в SA-MP как-то уживались с такими циклами и никто не умирал, что лишь подтверждает мои слова о бессмысленности пессимизации :)
Следовательно встречный вопрос, зачем тогда использовать sscanf, dc_cmd, mysql, давайте как в старые времена будет сидеть на файлах, использовать стандартный командный процессор, ведь было все норм никто не жаловался? :)
Потому что это удобнее?
sscanf позволяет разобрать кучу данных, используя всего одну строку
командные процессоры несут в себе кучу другого дополнительного функционала, помимо скорости обработки
mysql позволяет более удобно совершать выборку данных
Их, в первую очередь, используют потому что они упрощают определённые действия. А уже потом думают о скорости работы (в иностранном сегменте, например, во всю используют Y_CMD, который далеко не самый быстрый, но функциональный. И ничего, сервера не падают от перегрузки).
Да и сейчас ты как раз приводишь примеры оптимизации, а не пессимизации. Вот если ты сейчас сядешь и начнёшь искать способ ускорить и без того быстрый Pawn.CMD, добившись, в итоге, выигрыша в 0.00001мс, то это уже будет чистой воды пессимизация. А вот если ты выбираешь Pawn.CMD вместо обычного командного процессора, то ты, во-первых, ускоряешь обработку команд (не прилагая к этому никаких усилий, кроме, собственно, подключения плагина), а, во-вторых, улучшаешь синтаксис команд, не привязывая их к одному коллбэку.
Тогда опять же встречный вопрос , зачем тогда бегать по темам и давать всем советы как оптимизировать код , и как сделать лучше, если это вообще тебе не нужно ? :)
Опять же, не путай пессимизацию и оптимизацию. Я не против оптимизации.
Даже упомяну тот случай где ты спорили Я, Ты, Ziggi, Snegovik1337(вроде), помнишь? По поводу какой код быстрее работает.
Если ты заглянешь в ту тему и почитаешь мои сообщения, то в одном из них увидишь ответ на твой вопрос. А именно то, что я сугубо ради забавы проводил тесты, параллельно пытаясь показать на примере, что далеко не всегда "меньше кода" = "лучше".
И делать такие выводы, ты видимо не был еще в более сложных ЯП, по типу JS, BP, C(++, #, ), где каждый байт лучше оптимизировать . и занимается "пессимизацией", и отучать всех других - глупо :(
Громкое заявление, но, увы, даже тут ты не прав.
Важность оптимизации определяется не языком, на котором ты пишешь код, а, как я уже говорил выше, платформой, для которой ты этот код пишешь.
Так же, как я уже выше говорил, если ты однажды начнёшь работать по специальности "программист", твои оптимизаторские замашки никому не нужны будут, ибо в 99% случаев тебе нужно будет написать код в кротчайшие сроки и так, чтоб он просто работал без проблем. А если ты будешь сидеть над каждой строчкой по 10 минут, тебя быстро спишут со счетов, ибо из-за тебя компания будет терять прибыль, так как сроки будут увеличиваться.
Напоследок хочется подкинуть тебе простую задачку.
Представим, что у нас есть SA-MP сервер и есть код, который сервер оптимально обрабатывает за 5 миллисекунд. То бишь, обрабатывая код эти 5 миллисекунд, игроки не испытывают никакого дискомфорта и спокойно себе играют. Но тут ты видишь, что если половину кода заменить на #emit, а другую половину переписать в виде плагина, то можно выиграть 2.5 миллисекунды. Вопрос: стоит ли оно того?
Судя по твоей логике, естественно стоит. Только вот если отбросить понтокодерские замашки и обратится к здравому смыслу, можно понять, что игроки не почувствуют разницы. А раз игроки не почувствуют разницы (хотелось бы напомнить, что мод ты пишешь, в первую очередь, для них), то и смысла в твоих действиях чуть меньше, чем нисколько
И да, не нужно только опять писать что-то в стиле: "настрочил тонну текста, лень читать". Я лишь ответил на все вопросы, что ты задавал :) Так что если хочется меньше текста, то и самому стоит писать более конкретно)
Powered by vBulletin® Version 4.2.0 Copyright © 2024 vBulletin Solutions, Inc. All rights reserved. Перевод: zCarot