Всегда создаётся переменная, куда кладётся значение (или ссылка, если объект complex).
А вот for(int i=0; i< Array.length; i++) { ... } иногда позволяет переменную не заводить, работая напрямую с элементами массива/списка/etc., что иногда даёт выигрышь.
Со всякими процедурами - не сравнивал, в сравнении с join'ами перенос логики на уровень ORM сильно разгрузил машину. Раньше на форуме (когда размер таблиц постингов подобрался к миллиону, а объём перевалил за 3Гб) были sеlect'ы с join'ами, сразу подключающими всю нужную инфу об авторах постингов, аттачами и т.п... Так выборка от нескольких секунд шла до 15-20 секунд. После того, как на ORM перевёл - всё формирование страницы стало проходить за 0,1 - 0,3 сек. Тоже многовато, но потом используется статичское кеширование.
Хранимые процедуры интересно бы было пощупать концептуально, но пока не придумал, куда их гармонично засунуть :)
> Со всякими процедурами - не сравнивал, в сравнении с join'ами перенос логики на уровень ORM сильно разгрузил машину.
Ну как бы сейчас избавились от этой проблемы и ресурсы возросли в 4 раза :) хотя и раньше довольно шустро работало.
> Раньше на форуме (когда размер таблиц постингов подобрался к миллиону, а объём перевалил за 3Гб) были sеlect'ы с join'ами, сразу подключающими всю нужную инфу об авторах постингов, аттачами и т.п...
а индексы использовались ? просто в таблицах указаны индексы, но т.к. спроектировано все под другой проект, иногда попадаются запросы, которым принудительно нужно указать этим самые индексы. Запросы занимавшие порядка 10 секунд стали выполняться за 0,5 секунды. Плюс OPTIMIZE TABLE
Да уж естественно :) И индексы, и регулярные explain'ы на тему борьбы с filesort, и optimize table каждую ночь, и постоянная тонкая подстройка параметров mysql... :)
Не знаю как у вас в Java, а у нас в C# foreach требует от массива GetEnumerator(), который дает методы Current и MoveNext. Т.е. каждая итерация - вызов двух методов - бьет по процессору.