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



Выходит вид 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