Размер Include-файла

[Dogin]

Размер Include-файла

Приветствую господа !
У меня тут вопросец есть, только ногами не бейте....
Возник тут спор с одним челом, он утверждает, что размер файла, подключенного через Include или Require
существенно влияет на скорость выполнения скрипта. Т.е. если у меня подключен файл размером 200 кб, то это будет медленнее работать и займен больше памяти, чем если файл будет 20 кб. И естессно при большом траффике на сайте это даст свой отрицательный результат.
Помогите разобраться пжалста.

 

[SiMM]

Исходя из описанного утверждется, что

<?php sleep(20);?>

работает быстрее чем

<?php for($i=20;$i--; );?>

второй скрипт же длиннее.
Вам самому бредом не кажется Ваше абстрактное сравнение?

 

[Dogin]

Вот именно, что бред. Только я не могу это правильно товарищу объяснить.
И дело тут вовсе не в коде, а в его количестве.
Т.е. Если я подключу какой-нить фреймворк одним файлом размером 200-300 кб, то скрипт будет использовать больше памяти и будет больше нагрузка на сервер. Как мне правильно объяснить товарищу что в общем то большой (200-300 кб) файл с библиотекой функций не нагружает сервер при подключении.

 

[vovanium]

Загадочный спор, понятное дело что 200 КБ кода в любом случае будет парситься дольше и больше памяти занимать, чем 20 КБ. Но чтобы существенно... ну разве что если сами скрипты с дискет будут читаться.

А если ты имеешь ввиду разницу в скорости между одним файлом на 300 КБ, вместо 15 файлов по 20 КБ. То вариант с одним файлом будет быстрее, хотя и очень маловероятно, что это будет самым узким местом.

 

[Фанат]

Акселератор в любом случае снимет любые проблемы с объемом парсинга, но вообще, конечно, такие объемы - это жесть.

 

[Renny]

По поводу объемов и жести. В ZF например несколько тысяч фалов )))

-~{}~ 06.09.09 17:30:

Но я где-то видел сравнительные тесты по поводу кучи мелких фалов и одного большого. И действительно один большой - быстрее, но как правильно сказали - вряд ли это будет узким местом.

 

[Beavis]

Автор оригинала: Renny
По поводу объемов и жести. В ZF например несколько тысяч фалов )))

большинство из которых никогда не используются

 

[nexen]

include('dat.txt'); файл будет подключен без проверки того - подключался ли он ранее (если он существует)

include_once('dat.txt'); будет произведена проверка, и если файл не подключался ранее то он будет подключен (если он существует)

require('dat.txt'); файл будет подключен без проверки того - подключался ли он ранее (если он существует)

require_once('dat.txt'); будет произведена проверка, и если файл не подключался ранее то он будет подключен (если он существует)

вывод:
в случае если не знаешь подключался ли файл ранее или нет - используй вторые версии т.е *_once('dat.txt');
если же любом случае хочешь что либо подключить - первые

p.s.
естественно, как уже и сказали выше - память будет расходоваться прямо пропорционально от обьема файла и количества подключений.
вроде все верно изложил, - рекомендую к использованию include_once('dat.txt');

 

[Фанат]

офигеть к нам в деревню лектор приехал, мануал зачитывать

 

[Dogin]

В общем объясню, почему такой разговор зашел. Я делаю один очень большой проект и этого парнишку мне в помощь дали. И он начал разбивать уже готовые файлы скриптов на файлы, размером не более 10 кб. И все мои попытки объяснить ему что он не прав ни к чему не привели. И получается так: например есть у меня один основной управляющий файл index.php, но в некоторых случаях некоторые объявленные классы не используются, то он для этих случаев пишет другой обработчик. И получается что у меня огромная куча маленьких файликов - буквально по одной функции в каждом.

 

[Dreammaker]

Dogin,
если по функции в файле, то не здраво, если же каждый класс имеет свой отдельный файл, то это здраво.

Если нужен аргумент против использования кучи файлов, то куча мелких файлов будет дольше искаться по винту и будет больше нагрузка на файловую систему.

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

 

[флоппик]

куча мелких файликов будет сравнительно медленней за счет lstat к диску. Но как правило, различие настолько незначительно, что имеет смысл что то делать только на РЕАЛЬНОМ хайлоаде. Опять таки, оптимизаторы байткода, как мне показалось, охотней жрут крупные файлы, чем много мелких.

 

[Dogin]

Спасибо, попробую убедить.

 

[zerkms]

И все мои попытки объяснить ему что он не прав ни к чему не привели.

может он не так и неправ, значит?

флоппик
учишь людей спичечной оптимизации?

 

[флоппик]

zerkms, смотря что считать спичечной. Сам я делать такое пока причины не вижу, нет у меня таких нагрузок. Но для принятия решения всегда нужно знать максимум фактов. Я честно написал, что прирост незначителен, в сравнении с потерями на доступ к бд, например. Но и тормоза lstat тоже недооценивать нельзя, с другой стороны.

 

[Фанат]

вот не хотел участвовать в дискуссии о спичечной оптимизайции . но блин это ж надо

большинство из которых никогда не используются

единственный человек, который написал по делу.

ПОЧЕМУ ВЫ ВСЕ СРАВНИВАЕТЕ ЗАГРУЗКУ БОЛЬШОГО ФАЙЛА С ЭКВИВАЛЕНТНЫМ КОЛИЧЕСТВОМ КОДА ИЗ МАЛЕНЬКИХ?
когда речь иде о том, что инклюд и так и так один, просто он или сразу большой, или выбирается логикой из маленьких.

 

[Dogin]

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

вот именно...

 

[Alexandre]

И естессно при большом траффике на сайте это даст свой отрицательный результат.

при большом трафе надо использовать акселлераторы, как указывалось автором поста выше, в этом случае по барабану - кол-во файлов. Влияет только время первой загрузки.

С точки зрения методики кодирования - каждому классу по файлу - это вполне нормальная методика.

грузить кучу кода, большая часть из которого не используется - это тоже не гууд.

если стремитесь к большим нагрузкам - используйте соответствующие методики. Не стоит заниматься спичечной оптимизацией.

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

 

[FractalizeR]

Автор оригинала: Dogin
И он начал разбивать уже готовые файлы скриптов на файлы, размером не более 10 кб.

Как ему это удается? У вас в проекте файлы с не-классами размером более 10кб?

 

[Adelf]

Если цель - убедить коллегу - можно ткнуть сюда - http://dklab.ru/chicken/nablas/49.html . Правда эту статью довольно сильно обсуждали и осуждали. По своему опыту - там правда. Я объединил файлы из Zend Lucene в один и загружаться стало в разы шустрее. Но акселераторы сгладили бы проблему.

Если твой коллега делает это лишь из-за того, чтобы получить именно по 10Кб файлы - по пальцам. Если он разделяет на файлы по логическому принципу - правильно делает. Если уж очень хочется в этом случае сэкономить на спичках - делайте сборку всех файлов в один перед заливкой на продакшен.