В различных источниках встречаются временами замечания касательно всяких деталей, определяющих быстродействие. Не всё из этого кажется справедливым, вот и хочется в этой теме наконец разобраться, что же из "мелочей" влияет на скорость выполнения сценариев и каким образом. - длины имён переменных/констант/ф-ий/классов & etc. Совершенно очевидно, что когда длина имени превышает какое-то значение, это должно негативно отразиться на ресурсоёмкости. Каковы эти значения длин, насколько это критично? - двойные и одинарные кавычки: вроде бы разница в том, что содержимое одинарных кавычек (обрамляющих например присваемое переменной значение) интерпретатор не обрабатывает на наличие каких-либо инструкций, в отличие от двойных. где всё наоборот. Соответственно это отражается на скорости, правильно? - включение файлов в сценарий: в чём разница между include и require? Во втором случае файл подключается раньше преобразования сценария во внутреннее представление, а в первом - подключается тогда, когда до него доходит очередь, то есть если файл нужно подключить в любом случае, а не при каком-то условии, то использовать следует второй вариант? Что-то здесь мистификации много, может быть кто-то в курсе?
1) это мне кажется несколько сомнительным.. особенно учитавыя то что только самоубийца будет называть переменные настолько длинными именами, чтобы это сказалось на производительности. максимум который могу прдставить - это 4 слова... больше - это бред уже. 2) действительно, если написать Код (Text): $a = 'boo'; echo '$a'; echo "$a"; то в 1 случ. выведется "$a" в во втором "boo". я вот лично везде использую одинарные.. в то же время врядли это сильно скажется на производительности в целом. хотя конечно без $a в кавычках скорость будет быстрей: Код (Text): echo "var a: " . $a
а относительно require - никакой мистификации. все так как вы сказали. всё что надо подключать в любом случае (конфиг например), надо подключать реквайером (тогда, если я не ошибаюсь, всё копмилится вместе - как 1 файл).. а если инклуд, то тогда код файла, который подключается, будет откомпилирован только вслучае если выполнение скрипта до этого инклуда дойдет - вот тут и будет задержка по сравнению с рекваером.
Все эти источники написаны людьми несведущими, неумеющими измерять производительность, и не понимающими, что это такое вообще. Все эти тесты построены по одной схеме: Берётся автомобиль Мерседес. Из автомобиля берётся коврик под ногами. И путём сложных вычислений делается радостный вывод о том, что применив другую технологию, можно коврик сделать дешевле на целых 50%! или даже 100!!! Цифры, поражающие воображение. бред. нет в этом вопросе можно всецело доверять документации.
Прежде чем категорично отвечать на вопрос нужно убедится в абсолютной верности ответа. Чисто логически: чем длиннее файл скрипта, тем больше памяти он занимает, тем больше времени он читается и т.д. и т.п. Чем длиннее переменная, тем больше времени уходит на ее нахождение в теле скрипта (ведь происходит сравнение строк). Ну и дальше в том же духе. Правильно. Опять же необходимость сравнения со списком замены в случае применения двойных кавычек занимает какое-то время. Но! Все это так, все это правда... Вот только один непродуманный SQL-запрос или отсутствие нужного индекса или неверно построенная логика (особенно неверно построенная логика) затормозит скрипт в тысячи (серьезно) раз больше. Конечно, без необходимости использовать двойные ковычки тоже нехорошо, но это не так страшно (если строки не по 10 тысяч символов).
Вот старенькая статья про все эти мелочи. http://php.spb.ru/php/speed.html Как следует из нее не такие это и мелочи. Это конечно интересно, но, имхо, обычно основные тормоза идут из-за неоптимизированной логики программы, а не неоптимизированных кавычек.
можно попросить осветить этот момент поподробнее? кто и зачем ищет имя переменной в скрипте, и какие именно строки сравнивают.
vasa_c вот как раз из этой статьи и следует, что всё это не просто мелочи, а мелочи, ценность которых пренебрежимо мала. Методику тестирования в таких статьях я показал выше. "статья в интернете" - это ещё не критерий истины. И читать её надо с умом, а не смотреть на циферки в восхищении.
Возможно, требуется более чёткая формулировка. Vigo Все эти вопросы - просто не те, которые должны волновать разработчика. Это не то, что следует оптимизировать. Никакого реального выигрыша, в реальных скриптах эта мышиная возня не принесёт. Оптимизации следует подвергать только тот код, который тормозит. В реальности, а не в воображении.
подискутируем тут, в помоечке... На что следует обратить внимание: 1. Пореже делать инклудинг (если можно обойтись, лучше обойтись) 2. Осторожно использовать циклы, следить за логикой цикла... (SQL-запрос в цикле - это жесть) 3. Не заменять БД файлами в больших проектах... 4. Не использовать регулярные выражения там, где их можно заменить строковыми функциями... Вот вроде и всё (по крайней мере вспомнил только это).... думаю всем остальным можно пренебречь... в любом случае код надо продумывать сразу, чтобы потом не возвращаться к нему для оптимизации...
Хм... а что тут подробнее? Есть парсер PHP. Он парсит скрипт. Все, что находится после знака $ (если этот знак не в одинарных кавычках или не в двойных кавычках и экранирован) и до пробела/конца строки/знака равно и т.д. (короче, любого знака, недопустимого для имени переменной) он считает именем переменной. Это имя он сравнивает с элементами списка имеющихся имен переменных (вот оно - сранение строк) и если такая переменная есть - вставляет значение, если нет - зависит от контекста и настроек: либо создает новую переменную, либо ругается, либо ничего не делает. Не вижу смысла писать заведомо более медленный код, если для этого не надо прикладывать никаких усилий (это я про кавычки). А про длины переменных: я больше стремлюсь к удобочитаемости кода ($prevposnum, $nextposnum), чем к сокращению имени ($ppn, $npn).
Рассуждения на тему того, что обработка переменной длиной в 5 символов производится быстрее, чем обработка переменной длиной в 6 - это выше моего понимания. В общем, я не хотел этого писать, но по-моему, люди делятся на две категории. На тех, кто умеет сравнивать большое и малое, и тех, кому это от природы не давно. Ну не умеет сравнивать абсолютные величины. Это как с дальтонизмом - не различает разницу между двумя цветами. Так и здесь. Он понимает только относительные цифры: "2 копейки - это аж в два раза больше, чем одна!" Офигенный прирост! 200%!!! Согласен - цифры завораживающие. Но вот сравнить ту самую копейку с общей стоимостью проекта, которая составляет миллионы и миллиарды рублей - у них почему-то не получается. Тест на способность отличать одно от другого - это, как раз, скорость в кавычках. Если человек думает, что пишет заведомо быстрый код, меняя одни кавычки на другие - значит разговаривать с ним бесполезно. Не потому что он плохой или неправильный. А просто отсутствуют в нём некие внутренние весы. И это при том, что воззрения его на предмет - чисто теоретические. Пара лишних процессорных инструкций, которые добавляются для поиска в строке пары дополнительных символов, разрастаются в их воображении до огромных жерновов, привязанных к ногам бедняжки-парсера. Воззрения - повторюсь - чисто теоретические. Поскольку измерить реальную разницу между заведомо быстрым и заведомо медленным (в их представлении) кодом естественно, не представляется возможным. Причём это встречается не только у программистов. Часто можно видеть таких начальников, которые коршунами экономят на скрепках, при этом выбрасывая миллионы на какие-то завиральные идеи. Но искренне верят в то, что налаживая учёт скрепок, обеспечивают экономию средств. Это же ничего не стоит. Зачем зачедомо выбрасывать деньги на скрепки?
Hight Все перечисленные пункты, кроме циклов, пожалуй, сами по себе не оказывают никакого влияния на производительность. та же самая разница между строковыми и регулярными, если выражение используется всего один раз, будет пренебрежимо мала. ключевое слово - пренебрежимо. И от таких советов получается один вред. Поскольку начинающий программист взял, заменил регулярное на строковое - и программа у него начнёт летать! =) Про инклюды я не понял, в чём заключается их негативное влияние на производительность. Про файлы я просто скажу, что игра "бойцовский клуб" была написана именно на файлах. И это ещё раз потдверждает мои слова о том, что нет рецептов. А есть профайлинг. Слово, которое, между прочим, до сих пор в этой дискуссии не произнёс никто. Да. Конечно же - структуру программы надо продумывать сразу. Но принимать во внимание надо реальные факторы! Реальные, а не бабкины пересуды про одинарные кавычки.
Хех... Забавно... какие воинственного характера дебаты вышли из скромненькой такой темы... В общем, ясно всё... Выходит, что всё это действительно верно, но совершенно неактуально, за исключением разве include. Хм... Спасибо за мнения =).
я вижу ты поболтать любишь... наверное считаешь себя мега-супер-пупер-прошаренным программером... я не буду с тобой спорить, мне влом и пользы от этого мало, отвечу один раз... и дам совет - читай книги и дави в себе манию величия... оказывают читай про файловую систему... лишние операции нам ни к чему... как по-твоему работает функция инклуд???!!! а если не один?! если 101 ?! даже в мане по пыху пишут про это, почитай... напиши скрипт в котором будет 101 серьёзное рег. выр., вначале скрипта возьми микротайм и в конце и вычти одно из другого - померяешь время выполения. сравни результаты... в зависимости от конфы сервера с определённого момента начнётся жестокая просадка по производительности... начинающий программист не должен знать про оптимизацию?! нам тупые кодеры не нужны... читай про файловую систему... уверяю, что при использовании БД скорость была бы заметно выше... чем больше проект тем выше скорость при использовании БД относительно файлов.... кстати ни разу не видел эту игру... вот CS - это да... а DOOM - эх, супер... и QUAKE, а ещё цивилизация от Сида Миера... как давно это было объяснять почему так, я не собираюсь, мне влом... читай книги... у меня всё... Hight