Как Вы работаете с функциями и классами

[su1d]

Как Вы работаете с функциями и классами

в php|architect пролетела ссылка на интересное обсуждение:

http://www.sitepoint.com/forums/showthread.php?t=154680
(англ.)

пацанчики там намекают на то, что если хранить ВСЕ функции и классы в ОДНОМ файле, то всё будет работать быстрее. свои мнения аргументируют.

а что мы думаем по этому поводу?

 

[Demiurg]

ссылку пока не читал, но прирос производительности в 1% стот того, что бы все в одну кучу пихать.

 

[tony2001]

the system IO time to locate each of the separate files is > the time require to parse additional non-required

я в этом очень сомневаюсь.

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

 

[su1d]

вынесу основную идею сюда.

(Peter Moulding: Blazing Site Performance Using Objects and Sessions. PHP architect, March 2003.):

Files are the curse of object-oriented programming...If you take 20 classes, place them in separate files, then run a script requiring all 20 classes, your script will run like a dog with a broken leg. Try the same script including 100 classes, and no matter how small the classes, the script will run like a dog with 3 legs broken. Now copy all the classes into one big include file and test again. Pow! you are back to the speed of light. Each file open costs you several times more overhead than each read.

-~{}~ 27.02.04 09:42:

переведу:

Файлы -- проклятие объектно-ориентированного программирования... Если у Вас есть 20 классов, и Вы разместили каждый в отдельном файле, и Ваш скрипт использует все 20, он побежит как собака со сломанной ногой.
Попробуйте то же самое с сотней классов, и, неважно -- насколько они малы, Ваш скрипт будет бегать как собака с тремя сломанными ногами.
Теперь скопируйте все классы в один большой файл и попробуйте снова. Вау! Снова летаем со скоростью света!
Открытие файла даёт в несколько раз большую нагрузку, чем чтение.

ессно, есть там дальше и противоположное мнение... =)

 

[tony2001]

If you take 20 classes, place them in separate files, then run a script requiring all 20 classes, your script will run like a dog with a broken leg. Try the same script including 100 classes, and no matter how small the classes, the script will run like a dog with 3 legs broken.

да-да, а если 200, то как собака с 5-ю переломанными ногами.
а если 300, то как с 6-ю.
и т.д.

1) эти файлы инклудятся 1 раз.
2) очень странно, что у кого-то инклуд файлов является единственной операцией.
3)
10 инклудов 1-го файла - Time per request: 67.72 [ms] (mean)
1 инклуд 10-тикратно увеличенного файла - Time per request: 77.32 [ms] (mean)

Лично мне разница в миллисекундах (еще и в сторону замедления!) не кажется настолько значимой, чтобы жертвовать удобством.

 

[Alien]

Ключевая фраза "Ваш скрипт использует все 20".

А если использует не все? Зачем вместо нужных сейчас 1-2-10 классов всегда грузить все остальные?

 

[Кром]

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

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

 

[Ямерт]

Т.е. для увеличения скорости предлагается хранить ВСЕ классы в одном файле? Скорость работы, может, и будет выше, чем когда классы хранятся по отдельности - да вот только разработка и поддержка системы превратится в кошмар - особенно если разработчиков несколько.
Я в текущем проекте храню каждый класс в отдельном файле - в данном случае это очень удобно, потому что в общем у меня порядка 50 классов. Если слить это всё в один файл...брр...

В общем, если утрировать, то по идее авторов идеи надо вообще ВСЮ логику хранить в одном скрипте - ведь так будет работать быстрее! А ещё лучше убрать все переносы строки , табуляцию и лишние пробелы - ведь скорость тоже повысится!

 

[Popoff]

В принципе, можно написать компоновщик, который, после окончания работы с кодом, будет собирать все библиотеки классов и функций, и влючать их в основной файл.

Очень интересная идея Я как раз сейчас разрабатываю систему для защиты исходных текстов без кодирования: удаляю пробелы и комментарии, переименовываю переменные и функции... Я как-то и не подумал даже, что можно еще и все инклюды на месте обработать =))

 

[Линк]

"некоторые пишут как на С++ - инклудят файлы по N килобайт"(с) кто то из этого форума

Прирост производительности (тем более, его нет, как показал Tony2001), это еще пол дела.
А как же модульность?
Я сменил объект, на другой объект того же интерфейса (скажем что бы перевести продукт с SQL на файлы), и мне надо лезть в исходные коды, дабы заменить объект другом?
Куда проще банально перезаписать файл.
А уж о варианте с закодированными файлами, я вообще не говорю.

I like to have one file per class

аналогично))

 

[su1d]

Ключевая фраза "Ваш скрипт использует все 20"

конечно, это и есть противоположное мнение.
т.е. include-on-demand -- достойный ответ. благо, в РНР5 ввели оч полезный __autoload().

-~{}~ 27.02.04 10:58:

I like to have one file per class

можно сделать небольшую build-систему:
делаешь make и всё собирается в один файл, а поддержка ведётся с кучей мелких файлов.

 

[AnToXa]

хм, а у вас что все сильно тормозит, что вы уже начали оптимизировать инклуды?

или вы все тут в яху работаете?

 

[Silent]

> 10 инклудов 1-го файла - Time per request: 67.72 [ms] (mean)

Это что, был один и тот же файл? По этой фразе непонятно, что именно делалось.

 

[tony2001]

да, один и тот же.

 

[Silent]

Гм... А с кешированием как быть? Если уж замерять такие тонкие вещи, как скорость доступа к диску, нужно записать туда тестируемые файлы так, чтобы они физически находились в разных местах диска (чтобы кеш диска не влиял на результаты), перезагрузить компьютер, чтобы очитить кеш диска и операционной системы. После этого можно запустить тест. Один раз, чтобы исключить кеширование. А иначе эти милисекунды ни о чем не говорят. И что ты замерял вообще не понятно. Я уж не говорю о том, что инклюдить один и тот же файл 10 раз и потом говорить, что это очень быстро, несколько несерьезно.

 

[Demiurg]

Я не понимаю, что за погоня за врагами общества ?
Знаете такой принцип 80/20 ? так вот, 80% кода исполняется 20% времени а 20% кода исполняется 80% времени. include, по моему глубокому убеждению относится к 80%, и при увеличении скорости инклуда в 2 раза, общая производительность увеличится в лучшем случае на 10%.

Могу привести подобный пример:
в с++ оператор пост-инкремента(a++) реализуется посредством оператора пре-инкремента(++a), поэтому пре-инкремент работает быстрее. Практически все, кто хорошо знаком с С++ это знают, некоторые в нейтральных случаях приучили себя использовать пре-инкремент. Но вряд ли кто то будет выискивать у себя в коде пост-инкрементные операторы и приводить их в преинкрементные ради проихводительности, разве что в критичиских участках программы.

 

[trigger]

Согласен с Demiurg.

Детский лепет!, как сказал бы Romik_Chef (сорри если неправильно написал)

 

[tony2001]

Silent
>Я уж не говорю о том, что инклюдить один и тот же файл 10 раз и
>потом говорить, что это очень быстро, несколько несерьезно.
а инклудить 100 файлов и говорить, что это очень медленно - это серьезно?
читай Демиурга, он правду говорит.

 

[Silent]

tony2001
В последовательности тебе не откажешь, чего нет, того нет. Сначала с цифрами в руках доказал, что десять маленьких файлов подключить быстрее, чем один большой. Теперь говоришь о том, что 100 маленьких уже будет медленнее. Откуда же такая нелинейность? Тебе она не показалась странной? Любого инженера за такие измерения выгнали бы с работы с позором. А то наизмеряют чего-то, а потом самолеты падают. А программисты ничего, жуют, что подадут, человек ведь все измерил. А что он там измерял, никого не интересует.

P.S. Просто меня на физмате приучили осторожнее обращаться с цифрами. Болтать можно что угодно, но если приводишь результаты измерений, нужно быть готовым к тому, что люди попробуют воспроизвести их.

 

[tony2001]

Silent
извини, цифрам тебя на физмате научили, а как насчет читать?
мне достаточно неприятно, когда мои слова настолько извращают.

для особо одаренных повторяю облегченной форме:
тестить 100 инклудов и говорить "ах-ах, как это медленно!", при том, что больше 20-ти инклудов (~120 ms) в проектах не встречается - это умнО?
или на физмате не объясняют понятия "узкое место"?
у тебя давно инклуды стали узким местом в проекте?