За последние 24 часа нас посетили 30597 программистов и 1801 робот. Сейчас ищут 1010 программистов ...

Сильно ли объявление функций потребляет ресурсы

Тема в разделе "Прочие вопросы по PHP", создана пользователем PCSpeaker, 31 мар 2009.

  1. PCSpeaker

    PCSpeaker Активный пользователь

    С нами с:
    26 дек 2007
    Сообщения:
    84
    Симпатии:
    0
    У меня есть файл в котором собраны все функции вида
    function {
    }
    Вставляю этот файл с помощью include на все страницы и уже на каждой из страниц использую нужную. Насколько сильно это потребляет ресурсы? функции вроде бы не выполняются, а только объявляются. Может стоит каждую функцию записать в отдельный файл и вызывать на страницах только те, что требуются или это излишне?
     
  2. У тебя уже стопицот тыщ посетителей, что узким местом у тебя стали обьявления функций?
     
  3. Mr.M.I.T.

    Mr.M.I.T. Старожил

    С нами с:
    28 янв 2008
    Сообщения:
    4.586
    Симпатии:
    1
    Адрес:
    у тебя канфетка?
    сильнее потребляет инклюд
     
  4. PCSpeaker

    PCSpeaker Активный пользователь

    С нами с:
    26 дек 2007
    Сообщения:
    84
    Симпатии:
    0
    флоппик, >10.000 посетителей в сутки, около 400 одновременно онлайн, поэтому ищу любые места в коде, которые снижают производительность.
    Mr.M.I.T., спасибо, из этого уже можно делать какие-то выводы.
     
  5. Можно к гадалке сходить, я думаю.
     
  6. akrinel

    akrinel Активный пользователь

    С нами с:
    26 янв 2009
    Сообщения:
    955
    Симпатии:
    1
    Адрес:
    Spb
    PCSpeaker, пытаться наугад найти места в коде где что-то тормозит при большом объеме исходников долгое и нудное занятие. Поставь себе профайлер.
     
  7. alexey_baranov

    alexey_baranov Активный пользователь

    С нами с:
    3 фев 2009
    Сообщения:
    647
    Симпатии:
    0
    Адрес:
    Сургут
    повышать производительность- это хорошо.
    но такие работы не должны доходить до абсурда. я слышал аналогичные рассуждения на тему того, что и от объектов надо отказаться.

    я думаю, что если все разумные ресурсы для увеличения производительности исчерпаны и остались только неразумные, стоит переключить внимание на железо. А один файл с 1000 функций или 100 файлов по 10 функций в каждом не изменят ситуацию. Изменения будут, но не соизмеримые с затратами.

    Я знаю, что после того, как на ZF сделают высоко нагруженный проект, все классы сливают в один файл и это как- то сказывается на скорости. Но эти изменения незначительны.
     
  8. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    alexey_baranov
    Изменения кстати значительны. Другое дело что на самом выполнении кода не сказывается - да, а вот подгрузка 30-40 файлов для интерпретатора как раз даёт ту саму задержку, в запущенных случаях очень большую. На эту тему есть исследование в и-нете.
     
  9. Psih, оу, это безусловно узкое место для ресурса с одновременными 400 униками )
     
  10. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    флоппик
    Вобщем-то влияние было описано на примере Zend Framework в этой знаменитой набле: http://dklab.ru/chicken/nablas/49.html :) Читать с ["Мой скрипт вместе с библиотеками занимает 5 МБ, как же быть?.."]
     
  11. Я не сказал, что не влияет. Я сказал, что у него не ZF, и не те обьемы что бы затруднять себе же разработку (я же не думаю, что у него автоматический деплой) сливанием в один файл. И узких мест у него еще дофига в других, более нуждающихся в оптимизации местах. если вообще нуждающихся.
     
  12. Mr.M.I.T.

    Mr.M.I.T. Старожил

    С нами с:
    28 янв 2008
    Сообщения:
    4.586
    Симпатии:
    1
    Адрес:
    у тебя канфетка?
    что взять ключём для слияния библиотек в один файл? урл? тогда файлов будет куча
     
  13. alexey_baranov

    alexey_baranov Активный пользователь

    С нами с:
    3 фев 2009
    Сообщения:
    647
    Симпатии:
    0
    Адрес:
    Сургут
    тоже через все это проходил. это не наш путь. когда пол года назад стало заметно не хватать скорости, как- то не приходило в голову экспериментировать с require_once(). время жаль на такую работу. просто написал служебку и где- то через три месяца она всплыла. теперь и сервак новый и работы бесполезной делать не пришлось. это разумный подход.
     
  14. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    Вообще правильный include_path позволяет ОЧЕНЬ сильно сократить время обработки запроса, в среднем на 30%, с большими include_path с кучей директорий и того больше.
     
  15. PCSpeaker

    PCSpeaker Активный пользователь

    С нами с:
    26 дек 2007
    Сообщения:
    84
    Симпатии:
    0
    Проблему решил перебравшись на выделенный сервер =)
     
  16. [vs]

    [vs] Суперстар
    Команда форума Модератор

    С нами с:
    27 сен 2007
    Сообщения:
    10.559
    Симпатии:
    632
    Правильный - это какой?
     
  17. kostyl

    kostyl Guest

    Правильный - это какой?
     
  18. kas1e

    kas1e Активный пользователь

    С нами с:
    6 апр 2009
    Сообщения:
    280
    Симпатии:
    0
    Погляди в сторону оптимизации запросов в базу и их кэширования. Очень поможет.
     
  19. alexey_baranov

    alexey_baranov Активный пользователь

    С нами с:
    3 фев 2009
    Сообщения:
    647
    Симпатии:
    0
    Адрес:
    Сургут
    вот вот и я тоже пришел к тому, что до бесконечности увеличивать скорость только кодом не получится.
     
  20. Psih

    Psih Активный пользователь
    Команда форума Модератор

    С нами с:
    28 дек 2006
    Сообщения:
    2.678
    Симпатии:
    6
    Адрес:
    Рига, Латвия
    [vs]
    kostyl
    Это когда первой идёт та директория, в которой лежат нужные файлы. По умолчанию include path содержит в себе кучу системных директорий и только потом уже идёт поиск в текущей, т.е. с относительными путями получается долгий поиск.