В ходе очередных кодо-исправление возник такой вопрос!
Почему столь значительные разницы при выполнении казалось бы одинаковых операций?   



Выходит вид while (list($ind, $val) = each($bl_ar)) на и более быстродействующий для обхода массива ?

В реальной жизни разница незаметна.

И при чем здесь "Скорость работы str_replace", хотелось бы знать.

ты пробовал в разных php скриптах? всмысле не в одном? можнет он после первого вызова как-то оптимизировал массив?

мало того что ворох орфографических ошибок, так и кроме str_replace функций не видешь?

Данные куски кода пробовал как вместе, так и раздельно, результат примерно одинаковый. 
Меня интересует почему вариант  
является в  17 раз более быстродейстующим, чем

 

awers, вопрос нужно учиться читать внимательнее, а для флуда есть другие разделы  



Это сообщение отредактировал(а) KEM - 17.3.2008, 16:14

Ну если интересует - скачай исходный код, да посмотри - как реализован тот и другой вариант.
Вопрос ведь не имеет никакой практической ценности, а представляет чисто академический интерес.

В РНР есть миллион мест, где можно задаться точно таким же впросом. сравнивать скорость обработки строк в одинарных и в двойных кавычках, например.
Но тратить на это свое время врядли кто-то будет. Так что, если тебе так уж любопытно - смотри в исходниках.

KEM, а Вы уверены, что эти варианты на второй и последующих итерациях делают одно и то же? ;)

hint: найдите 1 отличие между конструкцией с while(each(...)), показавшей такой "феноменальный" результат, и подобной ей конструкцией в мануале, приведенной в качестве эквивалентной для foreach-а.

Это сообщение отредактировал(а) SelenIT - 17.3.2008, 16:57

Feldmarschall, ну почему же, с практической точки зрения давольно важно ели нужно максимально быстро обойти большие массивы данных.
SelenIT, конечно не одно и то же )
Для чистоты эксперимента,  если каждый элемент целочисленного массива увеличивать на 1, то вариант foreach при 5000 итераций явно отстаёт примерно в 22 раза!
Вот и весь академический интерес...  

KEM, еще бы ему не отставать. Он ведь честно проходит весь массив все полмиллиона раз. А вайл с листом несколько халявит...   

Да, написано "Скорость работы str_replace", разве не так?

KEM, на phpclub.ru была статья по оптимизации. Там рассказано почему и что быстрее и в каких случаях стоит применять тот или иной вариант.

KEM, 
Если не изменяет память, foreach копирует массив в памяти, именно с этим связаны его удобные свойства для программиста и некоторая медленность. Обрати внимание на синтаксис остальных циклов, и становится видно, что foreach необходимо совершать дополнительные операции с массивом(копирование, вычисление размеров) чтобы предоставить такой синтаксис.

KEM, подсказка "в лоб": каково быстродействие
и чем это (как и foreach) отличается от изначального "казалось бы" самого быстрого варианта?

KEM, для полноты теста предлагаю свой вариант. Думаю он будет самый быстрый (если главное - это скорость):

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

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

И вот если твоему приложению надо максимально быстро обойти большие массивы, то думать надо не о том, как ловить микросекунды, а о том, чтобы этих массивов в приложении не было.

mishaSL, Ваш вариант оказался наиболее быстрым =)

SelenIT,   "reset($bl_ar); " да действительно косяк )

Feldmarschall, очень интересно было бы заслушать Ваш вариант на тему обработки списка e-mail из текстового файла, к примеру выборки по доменам?

awers, статью обязательно поищу и почитаю, т.к. вопрос очень интересует!

Подведу небольшой итог умозаключений в наглядной форме   





Господа...   


Это сообщение отредактировал(а) KEM - 18.3.2008, 01:13

Так, может, Вам не str_replace, а обычный rtrim нужен? Он всяко побыстрее должен быть... И вообще, почему бы не использовать нормальную БД и извлекать любые выборки сразу в готовом виде?

это я к примеру сказал, мало ли случаев жёсткой привязки к конкретным условиям, тем более опять же работа "напрямую" с диском и памятью. быслрее работы через демоны БД.

Это бабка надвое сказала. Т.е. при сопоставимых условиях оно так, но, к примеру, выбор 100 значений из 100k по индексу явно будет побыстрее, чем перелопачивание всех этих 100k записей циклом. А если каждый раз грузить их все в память - то и подавно...

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

Добавлено через 1 минуту и 41 секунду
впрочем, давайте не оффтопить.
либо есть проблема и её надо решить(не исключая рефакторинга структуры и алгоритма), либо идем во "флейм" и там обсуждаем в духе "а что, если у меня нет СУБД" или "а у меня жесткая привязка к конкретным условиям" и т.д.

SelenIT, ну это не бабка сказала, на этом так сказать гугл стоился
Условностей и возможностей действительно много, и для их обсуждения есть отдельные разделы, не будем флудить

Уж точно не на полном переборе многотысячных массивов. Тем более на ПХП .

KEM, и какова конечная цель этой обработки?
Впрочем, можешь и не трудиться придумывать очередную сказку. Задачи в вебе делятся на две категории - выполняемые при обращении пользователя к сайту, и  запускаемые на регулярной основе в фоновом режиме.
Для обоих вариантов твои проблемы не актуальны. В первом случае мы обязаны избавиться от обработки больших объемов информации, а во втором нам эти копеечные затраты и вовсе по барабану. Учитывая же весовые коэффициенты задач (к примеру, парсинг нескольких букв и собственно отправка мейла) мы окончательно приходим к полной бессмысленности таких "измерений".

Мне кажется, это не оффтопик.
Это самая важная фраза во всем обсуждении.
Похоже, человек не понимает принципов использования базы данных, и, как я считаю, важнее всего ему эти принципы объяснить. Даже если придется для этого поменять раздел на какой-нибудь флейм.

KEM, дело в том, что получение от "демона БД" десятка записей будет всяко быстрее самостоятельного чтения сотни тысяч строк напрямую с диска и памяти. То есть, "надвое сказала" - это только в случае, если мы свои сто тыщ запрашиваем у БД, а потом нова парсим сами, в своей памяти. Но даже в этом случае ещё не факт, что "сами будем быстрее". Но суть-то не в этом. БД нам нужна не как замена текстового файла, который мы читаем целиком. А именно как демон, у которого мы запрашиваем только нужную информацию. Которая составляет мизерную долю от общего объема хранимых данных.

Feldmarschall, ну что же вы так привязались к этому примеру с текстовым файлом ? файл же может быть не только текстовый)  Да и принципы работы СУБД я понимаю замечательно, для каждой задачи есть свои оптимальные пути решения и не всегда это БД, есть масса задач для которых собственные файлы, типизированные или нет, подходят куда лучше.


Вообще согласен, но при фоновой обработке, тем более в условиях одной физики и приличного объема данных, эти "копеечные затраты" могут стать боком. Если вы можете увеличить производительность хотя бы на 5% делайте это!

Привязался я к примеру потому, что он высосан из пальца.
Потому, что в реальности таких примеров не существует.
Да, есть масса задач для которых собственные файлы, типизированные или нет, подходят, не "куда лучше", разумеется, а примерно так же, как и БД.
Но это не тот случай, когда в файле десятки тысяч строк!

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

Если же ты хочешь продолжать стоять на своем, то будь добр привести здесь реальный, практический случай. Только учти. Что беседуют с тобой здесь не мальчики, а профессионалы. Которые со всякими случаями сталкивались. И хорошо отличают реальность от фантазии. Поэтому или придумывай хорошенько, или сразу откажись от этой затеи. При этом задача должна быть реальной именно для тебя. Всякие гугли приводить в пример не надо - заранее предупреждаю - сядешь в лужу гораздо хуже.

))))))))
очень милые изречения, напомню что настоящий профессионал никогда себя таковым не считает. т.к. его личный опыт ему этого не позволит. А ещё профессионалы не переходят на личности т.к. они "не мальчики". Ну это так к слову, я не считаю нужным вам что то доказывать или обьснять, я высказал свою точку зрения и останусь при ней, т.к. ваша не аргументирована, если человек считает технологию которую ему дали единственным средством решения задач, это просто значит что он не видит и не хочет видеть дальше своего носа.
Прошу тему считать исчерпаной   

Что и требовалось доказать