Вы не зашли.
Главная » PHP » Тесты производительности
#21. LONGMAN Off (0)
Участник
2009.03.10 02:02
Интересно было бы сравнить ещё и while, do while, for и foreach
#22. Gemorroj Off (107)
Administrator
2009.03.10 02:02
по ссылке в первом посте достаточно много информации на этот счет. http://wapinet.ru/textbook/speed.htm думаю повторяться не стоит.
#23. LONGMAN Off (0)
Участник
2009.03.10 02:02
Да я знаю эти тесты от Бородина, но интересно будет ещё тесты именно на Windows XP SP3
#24. Gemorroj Off (107)
Administrator
2009.04.10 19:07
Теперь PHP 5.3

файла не существует
error_reporting(0);

file_get_contents("xxx");
16.7541
17.4581
17.4037
14.7361
14.7268

@file_get_contents("xxx");
17.8958
16.7447
16.2829
14.8839
14.8261
а теперь ставим error_reporting(2039);
50.000 проходов
file_get_contents("xxx");
294.0389

@file_get_contents("xxx");
7.6748
такое получается из-за забивания буфера ошибками.
#25. JInn Off (2)
Участник
2009.04.12 17:05
Я где то читал что при использовании знака @ код работает медленне в 7 раз... Врут?...
Как все таки сложно быть ботом...
#26. Gemorroj Off (107)
Administrator
2009.04.12 17:05
я тоже такое читал, поэтому и решил проверить. В случае с file_get_contents выходит врут.
#27. JInn Off (2)
Участник
2009.04.12 18:06
А можешь проверить с этим же значком, только истинное утверждение? Возможно в том случае, если не будет никаких ошибок, результаты будут другими?
Как все таки сложно быть ботом...
#28. Gemorroj Off (107)
Administrator
2009.04.19 15:03
10.000 проходов
file_get_contents(__FILE__);
// 6.7937
// 6.9678
// 6.5534
// 6.8022
// 6.7107

@file_get_contents(__FILE__);
// 7.1111
// 7.2268
// 6.8919
// 7.0816
// 7.0639
да, действительно, если файл существует, то подавление ошибок с помощью собаки замедляет работу.
#29. JInn Off (2)
Участник
2009.04.19 16:04
Примерно 0.3 секунды за 10000 проходов. Не так существенно, как говорят, но все равно прилично
Как все таки сложно быть ботом...
#30. Gemorroj Off (107)
Administrator
2009.05.03 17:05
Сегодня пол дня воевал со следующим SQL запросом
Код:
SELECT DISTINCT `links`.`id` , `links`.`id_user` , `links`.`link` , `links`.`link_text` , `links`.`timeout` , `links`.`timeout_ip` , `links`.`timeout_ip_browser`
FROM `links` , `users`
WHERE `links`.`id_user` <>0
AND `links`.`16_17` = "1"
AND `links`.`sunday` = "1"
AND `links`.`in` >0
AND `links`.`on_off` = "1"
AND `links`.`comp` = "1"
AND `users`.`ban` = "0"
ORDER BY `links`.`id` DESC;
Требовалось оптимизировать... Результатов выборки без DISTINCT примерно 80.000 с DISTINCT примерно 150.
Так вот скорость мягко говоря удручает. Более 2-х секунд на средненьком сервере.
Решилось следующим образом
Код:
SELECT `links`.`id` , `links`.`id_user` , `links`.`link` , `links`.`link_text` , `links`.`timeout` , `links`.`timeout_ip` , `links`.`timeout_ip_browser`
FROM `links` , `users`
WHERE `links`.`id_user` <>0
AND `links`.`16_17` = "1"
AND `links`.`sunday` = "1"
AND `links`.`in` >0
AND `links`.`on_off` = "1"
AND `links`.`comp` = "1"
AND `users`.`ban` = "0"
GROUP BY `links`.`id`
ORDER BY `links`.`id` DESC;
Совсем небольшие изменения в коде, а запрос выполняется примерно за 0.2 секунды. В принципе тоже не ахти, но прогресс все равно очень заметный. В 10 раз.
Страниц: 1 2 3 4 5 Все
Главная
WEB
PunBB Mod v0.6.2
0.016 s