Значит я не ошибся, когда несколько дней назад сделал предположение, что вы задали вопрос не для того, чтобы определиться, а для того, чтобы получить процент поддержки в пользу процедурного стиля и со спокойной душой начать на нём писать
Естественно, не ООП Таких накладных расходов оно не требует, тем более в динамическом языке типа PHP, где в принципе значительного увеличения быть не может - у нас все переменные, фактически, в куче. В компилируемых языках типа C++ разница в накладных расходах больше, поскольку выделение памяти в куче более дорогая операция, чем просто сдвиг стека на n байт для локальных переменных или выделение памяти на этапе запуски программы единовременно для всех глобальных.
Чтобы раз и навсегда поставить точку - просто сравните время выполнения одинакового функционала на функциях и ООП, я для замеров написал себе специальный класс: PHP: class Runtime { private static $start; private static $mem_start; public static function start() { self::$start = microtime(); function convert($size) { $unit = ['b','kb','mb','gb','tb','pb']; return @round($size/pow(1024,($i=floor(log($size,1024)))),2).' '.$unit[$i]; } self::$mem_start = memory_get_peak_usage(); } public static function end() { echo '<p>Время вывода страницы: '.(microtime() - self::$start).' сек.</p>'; echo '<p>Расход памяти: '.(convert(memory_get_peak_usage() - self::$mem_start)).'</p>'; } } Runtime::start(); // Код, выполнение которого замеряем Runtime::end(); По моим тестам - функциональный код в ~25 раз быстрее ООП (тестировал на php 5.6) Но, пишу я все же на ООП P.S. Если пишите на PHP, но очень нужна скорость - я бы посмотрел в сторону KPHP
Это копейки. Человек пишет про разницу от миллисекунд к секундам, это уже серьёзно, но это не ООП, а кривые руки
меня слегка подбешивает сам типа вопрос "что быстрее". ну понятно же изначально, что короткий код быстрее длинного. что универсальность враг скорости и т.д. мне кажется топикстартеру не надо ничего доказывать, скорее всего кто-то недавно раскритиковал его старомодный код и теперь ТС ищет себе оправдание. или блин конкретная цифра в коменте просто из вакуума: 25х — а что именно сравнивается? можно сравнить скорость вызова простой функции и метода объекта. браво! только смысла в этом почти нет. ООП ≠ использование служебного слова "class". --- Добавлено --- TLDR; объектный подход подразумевает другой способ мышления: когда функционал дробят и изолируют. определяют границы использования и контролируют зависимости. это будет дополнительная нагрузка, какое-то замедление. но это справедливая цена, если код неодноразовый. насколько или во- сколько раз такой код медленнее невозможно сказать в общем виде без контекста. абстрактно рассуждая, echo "Hello world" будет в стопицот раз быстрее чем то же самое, но в MVC на каком-нибудь фреймворке. однако чем задачка сложнее, тем разница меньше. но таки будет. если уж дрочить на скорость, то оцените что именно даёт доп. нагрузку. например, типично для фреймворков, сначала идёт инициализация всего и вся (bootstrapping), а потом начинается обработка запроса. собственно сам факт, что экшены оформлены в виде методов, а не функций даёт мизерный оверхед. самый большой расход — это бутстрапинг + роутинг. именно поэтому появился "микрофреймворк" Lumen — автор ларавеля постарался сократить процесс начальной загрузки и заменить тяжелый роутинг. а "микро-" он очень условный. но echo "Hello world" всё равно его побеждает по скорости )))
автомобиль вроде является совокупностью болтов, гаек и прочего дешевого хлама. подсказка: он должен быть собран правильно, чтобы иметь ценность.
Пришел ко мне как-то заказчик и говорит: "Хочу самописный интернет-магазин!" Читаю техзадание - совершенно тривиальный магазин, использующий стандартный функционал. Говорю заказчику: "Зачем вам самописный сайт и что вы под этим понимаете? Есть куча готовых решений, которые можно установить за час и завтра ваш магазин будет уже функционировать." Слышу довольно-таки распространённый ответ: "У моей жены есть племянник, так вот брат мужа его сестры программист (умеет настраивать каналы на телевизоре) и он сказал, что хороший сайт должен быть написан вручную в блокноте! А готовые решения - это разводилово." Вопрос: зачем писать все функции заново, если есть готовые? Тогда и фреймворки нахер не нужны! Давайте будем каждый сайт с нуля писать! Маршрутизация, галереи, загрузка файлов всё будем писать каждый раз заново! Будем заниматься отладкой каждой функции, искать где забыл поставить точку с запятой или где закралась кириллица! Я считаю, что программист должен уметь написать любую функцию с нуля, но так же он должен уметь грамотно использовать готовые библиотеки и готовые решения. Это оптимизирует трудо- и временные затраты.
главный вопрос был в скорости. процедурный быстрее. то, что ООП тоже может быть быстрым - не интересует. Будем считать что я из тех людей кто уважает масл кары с атмосферными движками, а японок с кучей софта и турбо - ширпотребом. пхп мне вообще нужен для реализации собственных целей, а не для заказов со стороны. так что мне абсолютно не интересно если "без знаний ООП не берут на работу" или другой прогер не сможет читать(не сможет - значит он не прогер). Топик стартер не искал себе оправданий и его старомодный код никто не критиковал. ООП более медлителен по сравнению с процедурным? Да. Тогда и нет надобности разбираться в ООП. Все. Вся суть топа. это кривые руки, когда одно событие обрабатывается 70 раз. А знаете почему кривые руки? Потому-что 90 процентов заказов на пхп - это интернет магазин, сайт визитка и т.д. А дальше фреймворки, чужие библиотеки и т.д. Программирование - это логика. Фреймворк - это фронтпейдж для пхп. тотальная стагнацию мозгов и не желание учиться, что в принципе и осуждать нельзя, т.к. так устроен человек. Потыкал месяц редактор и уже пишешь софт для заказа пиццы на айфон. И это не плохо, неплохие деньги. Но это не программист. Не хочу никого обижать. @Sergey_Tsarev я различаю интернет магазин и свое т.з. очень хорошо. если бы все было так просто, я бы взял опенкарт и не парился. я бы и сам написал, но я не знаю кучу мелочей которые решаются гуглом. просто решил не париться, ну теперь придется самому. --- Добавлено --- @Walk ну не знаю. как-то не вызывает доверия, раз уж он транслирует в си, не лучше писать сразу на си? возникают аналогии с Java. PhpStorm у меня загружается дольше Фотошопа =) Вообщем народ, тема давно исчерпала себя и тут уже оправдываюсь перед защитниками ООП. Кому нравиться - пусть использует. Мне не нравиться. Возможно с опытом примкну к стану любителей ООП. Судить мне особо опыт не позволяет, я скоро начну новую тему где буду спрашивать как работает авторизация, каким образом связаны разные скрипты одним логином(наверно сессии, но я толком еще не читал). Я к тому что не нужно мне доказывать, я не на том уровне сейчас. Пока что этой темой я понял что на данном этапе мне ООП не нужен. Может и вообще не понадобиться.
Лично знаю пример, когда монолит и процедурки без фреймворков сказали ой, после того как количество обрабатываемых данных в час, стало гораздо больше, чем до этого в день. Зарешали микросервисы, фреймворки и ооп, ибо хоть и медленнее, но масштабируется горизонтально и потому по факту быстрее. Решают не микросекунды, а возможность скаллировать приложение под нагрузку. Такие дела, господа самописцы ))
Так о том и речь. Вы пишете, что вам собрали чат из готовых функций. Чем это плохо если чат работает и выполняет свои функции??? Другой разговор если вам требуется какой-то уникальный функционал - тогда да, идет сотворение уникального кода под конкретную задачу. А на счет ООП... вам кажется что процедурный код лучше пока вы не столкнулись с масштабируемым проектом. Да и потом технологии не стоят на месте. Современные мощности позволят с легкостью использовать современные технологии не боясь загрузки сервака. Я начинал как дизайнер- верстальщик. Верстал ультракроссбраузерные сайты. Но в определенный момент понял, что есть css3 и html5 и нельзя вечно подстраиваться под ослика шестой версии. Свой последний проект делаю на Laravel, и frontend делаю на flex. и пошли на фиг пользователи допотопных браузеров. Иногда стоит забить болт на технологии 90-х годов и ориентироваться на будущее!!
У любого могут быть свои разные примеры, а маштабирование и скаллирование красивые слова но они и являются врагами скорости. Самописец может сделать быстрый сайт не потому что он умнее команды фреймворка, а потому что это не будет универсальным маштабируемым решением на любой вкус. 5 отдельных шаблонов будут быстрее чем 5 страниц на CMS. После того как сервер загрузил шаблон в оперативную память для него издержек уже нет, все что там есть обработается за мгновение (если уж там не совсем тупая логика), а у CMS сразу огромная база, куча разных подключаемых файлов, вот в этом и есть весь оверхед и скаллирование и маштабирование еще больше его увиличивает
Написал большую портянку, а потом подумал и удалил. Бестолку ) https://ru.wikipedia.org/wiki/Масштабируемость Молодец! А я возьму фреймворк nuxt, основанный на фреймворке vue, напишу в консоле nuxt:generate и оно мне из всей этой мешанины вернет 5 html страничек, один css-файлик и один js, которые будут работать в браузере, без cms, php, ООП и на любом хостинге способным отдать браузеру файлик. Что быстрее? )
Все-же 5 страничек у самописца могут подразумевать какую-то реализацию в виде приложения включающую например прием и валидацию данных, работу с БД и тп, а то вместо генерации можно копипастить "без cms, php, ООП" - без php не вопрос, а как с хостинга будет в браузер попадать? Ты не ответил недавно на вопрос по поводу токена в хедере, а о работе серверного js стоит ли что-то спрашивать
Тебе там @mkramer ответил. Мне надо было за ним повторить? Или пояснить тебе зачем нужны заголовки? Почему некоторые вещи лучше передавать именно ими? Где это используется? Ну чувак, я не @denis01 и не @Ganzal, титаническим терпением и желанием нести знание в массы не обладаю, извини )
Ты себя недооцениваешь я помню помню как ты вникал в портянку мутного кода чувака который тебя упрекал за обращения на ты, я бы не стал Просто если высказываешь свое мнение "надо так" то логично наверное обосновать почему, иначе зачем высказывать.
Там был разговор о передачи csrf-токена и что токен для get/delete-запросов он будет частью ссылки, ведь у них нет тела запроса и это типа небезопасно (да), т.к. пользователь всегда может скопировать / вставить ссылку. На что я привел пример кода, где токен передается не частью ссылки, а заголовком. Правда я так и не понял тогда, как delete-метод вообще смог стать ссылкой и зачем это нужно для get-метода, который по определению своему не должен выполнять действий, но это уже нюансы ) Что конкретно тебе не ясно? судя по всему дело было в пятницу. В пятницу и понедельник я добрый.
Я понял, спасибо. По теме все-же самописи или фреймворков, не все так просто, модульность готовых решений можно совмещать с индивидуальной архитектурой, иначе это может быть очень размазано тк готовые решения часто могут быть слишком универсальны и нести много лишнего функционала от которого не избавишься, приводящего к лишним затратам.
Сейчас бы прийти в сообщество разработчиков, и отмахиваться от очевидно профессиональных рекомендаций.
Нагрузка на php это ничто в сравнении с нагрузкой на бд. Тем более это очень легко маштабируется. Писать нужно не ради скорости а ради удобства.