что лучше

или

?

nmn, 

посмотрите msil, который получился в результате 
мне кажется, что коды эквивалентны и компилятор сам всё оптимизирует 

nmn, лучше использовать foreach.

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

проверил, не поленился  IL всё же разный, во втором цикле count вшит в проверку
но разница настолько минимальна (110мс на 100.000.000 итерациях), что всерьёз задаваться целью переписать все циклы, право, не стоит
ну разве что весь остальной код оптимизирован настолько, что там возможные потери ещё меньше

_______________

переписал тест, добавил foreach
относительно первых двух результатов картина сильно изменилась
теперь


Это сообщение отредактировал(а) mihryak - 21.12.2008, 12:42

а можно код теста?

Добавлено через 8 минут и 7 секунд

цикл foreach работает в разы дольше for, там же как и если сравнивать as,is и typeof

foreach примерно в 1,5 раза медленнее
но вот Array.Length оказался быстрее чем при использовании переменной

mihryak все таки хотелось бы посмотреть на код вашего теста

Это сообщение отредактировал(а) nmn - 21.12.2008, 20:09

вот первый тест, в котором foreach выигрывал у Length

обратите внимание, что в первом прогоне Length показывает результат почти в 3(!) раза лучше, чем в последующих 9. почему, интересно?

сейчас переписал тест - результаты расположились более ожидаемо

вот код:


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

На самом деле результат зависит от конфигурации - debug/release, от конкретного процесора, от размера кэша, от ОС, от фаз луны...
Например, вот release/a.Length на моей машине:

Вот release с константой. Кстати, массив не используется в цикле, можно сразу выбросить.

А вот foreach, видны проверки range. Но иногда работает все равно быстрее - луна помогает.

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

значит можно использовать foreach не боясь много(несколько порядков) потерять в производительности?





Это сообщение отредактировал(а) nmn - 22.12.2008, 04:12

имхо foreach не так показателен для массивов, как for.

PashaPash че эт у тя за IL такой ? смахивает больше на x86 assembler (intel).
вы под чистым .net -ом поглядите IL код.... там, глядишь, и до yeild дойдете мб (хз как там реализован foreach для массивов)....

nmn надо сравнивать скорости для разных массивов) а-то оно уже в кеше и всякая фигня другая...

foreach медленее, остальное всё фигня 8)

А это и есть чистый  x86 assembler, тот самый, в который IL скомпилировался. Странно сравнивать промежуточные результаты, если можно сравнить код, тем более что его умеет показывать сама студия. foreach для массивов все равно организован внутренними хаками, которые компилируются вот в такой забавный код. Никаких yield там нет, тупо цикл с проверкой границ.

Это сообщение отредактировал(а) PashaPash - 22.12.2008, 13:48

вот этого я не знал.. хм... теперь будем знать 8)

Вот и не лень вам писать эту чушь из раза в раз?
Причём опираясь чисто на синтетический тест, на практике всё зависит от конкретной ситуации, а написать синтетический тест, который покажет, что цикл с for работает медленнее цикла с foreach не составит труда хоть сколько-нибудь опытному .NET-программисту!

P.S. Особенно смешно смотрятся подобные метания с учётом того простого факта из практики, что пустых итераций не бывает, а в 90% случаев затраты на одну итерацию оказываются в разы больше, чем на внутренние механизмы foreach. В итоге вы в лучшем практическом(а не синтетическом) случае при 1000 итерациях выиграете от замены foreach на for приблизительно 0.1% от общего времени выполнения цикла. Безусловно это очень мощный стимул вовсе отказаться от foreach.       

source777, если не ошибаюсь, в одном из подобных топиков от Вас (тебя?) было сообщение, с упоминанием возможности объяснить, почему foreach действительно хорош, но из-за общего нервного тона дискуссии, ей (возможностью) воспользоваться было неуместно
можно ли это сделать здесь? безо всякой иронии спрашиваю

Да, было дело... И, как видишь, вновь нашлись люди, которые на основании синтетических тестов готовы бросаться в крайности...
Но обо всём по порядку, во-первых работа с массивами в .NET встречается довольно редко, в десятки раз чаще практическое применение находят классы-коллекции из System.Collections.Generic. В них foreach реализован гораздо более эффективно.
Во-вторых, перебор коллекции только ради перебора можно встретить лишь в синтетических тестах, я думаю, ты согласишься, что в реальном приложении код типа 

просто недопустим.
Отсюда мы приходим к важному выводу, что мы обычно перебираем коллекцию, чтобы выполнить с каждым её элементом некоторые действия...
А вот тут-то и выплывает неучтённый горе-авторами всяких синтетических тестов аспект:
доступ к элементу коллекции через итератор гораздо быстрее, чем через индексатор!!!
Т.е. из foreach обращаться к членам элемента выгоднее...
Эксплуатируя сей очевидный факт, легко написать синтетический тест, в котором for "проиграет" сравнение с foreach

В Release-версии этот код выдаёт примерно такие результаты:

Т.о. цикл с for оказался в 2 раза медленнее цикла с foreach.

Как видишь, стоило проигнорировать простой факт того, что доступ к элементу коллекции через итератор гораздо быстрее, чем через индексатор и производительность for растаяла в одно мгновенье. Ну и кому нужна такая оптимизация?
Естественно, легко догадаться как оптимизировать вариант с for, необходимо запомнить значение(точнее ссылку на него) текущего элемента во временной переменной, а не дёргать каждый раз индексатор.

Этот вариант выводит 354, т.е. время того же порядка, что и foreach, только писать больше букв пришлось...


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

Это сообщение отредактировал(а) source777 - 25.12.2008, 01:16

source777 Просто твой код не оптимизирован, потому и медленый for, а в foreach  не нада оптимизировать, потому быстрый, но в foreach уде время на преобразование и на оптимизацию.

Компилятор преобразовует foreach  в for  и оптимизирует, а неа преобразование йдут доли секунды.
Если вы умеете оптимизировать, то лучше пользуйтесь for, если нет то лучше foreach.

Это ошибочная точка зрения, домашнее задание тебе: посмотри MSIL-код и убедись в том, что код, сгенерированный foreach, принципиально отличается от кода, сгенерированного for.