Но выяснить это devel не помогает, только профилирование, только xhprof.
Странно, что об этом инструменте дебага так мало говорят, не всегда тормоза только из-за запросов к БД.
Оригинально. Т.е. не на продакшене допустимо использовать инструмент, который просто добавляет 1,5 минуты к времени загрузки страницы. Просто плохой модуль поставил коллега, для развлечения, наверное. Тут больше вопрос в другом - под оптимизацией почти всегда имеют ввиду сокращение времени выполнения запросов и текста скриптов. А способы профилирования и получения реальной информации о выполнении функций, особенно количественных характеристик времени и памяти - нет.
Или есть инструмент в devel'е или другом модуле, позволяющем увидеть критическое место именно в исходном коде?
Тот же самый xhprof мне помог обнаружить ещё несколько узких мест в модулях и поднять производительность. Не понимаю, почему не сделать подобный режим в "дев инструментах", или это табу?
Может просто потому что средства профилирования выбирает каждый сам себе? Можно разве что рекомендации дать чем лучше профилировать. Ну не писать же собственный профилировщик чтобы точно знать что он будет жить долго и счастливо, так же как и собственные разработки...
Комментарии
хм, http://drupal.org/node/160090
рекомендуют покахать ядро - отключив таксономию
не самый лучший вариант
> http://drupal.org/node/160090
Это для 5.x.
Та же проблема. Devel:
> Executed 695 queries in 368.42 milliseconds. Page execution time was 81463.66 ms.
Жуть.
Сделайте/поставьте admin_views и забудьте про ядрёные функции
Проблема была в моделе drupalforfirebug!!! Ужасный модуль.
Но выяснить это devel не помогает, только профилирование, только xhprof.
Странно, что об этом инструменте дебага так мало говорят, не всегда тормоза только из-за запросов к БД.
Так отключать дев инструменты нужно на продакшн, батенька
Оригинально. Т.е. не на продакшене допустимо использовать инструмент, который просто добавляет 1,5 минуты к времени загрузки страницы. Просто плохой модуль поставил коллега, для развлечения, наверное. Тут больше вопрос в другом - под оптимизацией почти всегда имеют ввиду сокращение времени выполнения запросов и текста скриптов. А способы профилирования и получения реальной информации о выполнении функций, особенно количественных характеристик времени и памяти - нет.
Или есть инструмент в devel'е или другом модуле, позволяющем увидеть критическое место именно в исходном коде?
Тот же самый xhprof мне помог обнаружить ещё несколько узких мест в модулях и поднять производительность. Не понимаю, почему не сделать подобный режим в "дев инструментах", или это табу?
Может просто потому что средства профилирования выбирает каждый сам себе? Можно разве что рекомендации дать чем лучше профилировать. Ну не писать же собственный профилировщик чтобы точно знать что он будет жить долго и счастливо, так же как и собственные разработки...