Сообщение #28 zyxer » 18.05.2020, 10:22
Так я неоднократно на форуме акцентировал внимание что анализ и сбор метрик производим через blackfire (
https://blackfire.io), также замечу что анализ периодически повторяется. Сравнивать с двойкой думаю не корректно, потому как по большому счету двойка написана в процедурном стиле (хотя там и есть new ...) но это не ООП подход. Вдаваться в дискуссию что лучше ООП или процедурка думаю выходит за рамки данного форума. Для тройки мы приняли решение писать её на ООП. Да, согласен что ООП подход сам по себе уже более ресурсозатратный по сравнению с процедуркой, но у него также не мало плюсов...
Также скажу что на экономию времени выполнения скрипта мы делали и будем делать достаточно большой упор, а вот на экономию памяти вторично. Это не касается ситуаций когда в выгрузках обнаружилось чрезмерное потребление памяти (там были гигабайты), такие моменты естественно будут правиться.
Также в будущих версиях будет добавлен некий функционал, который будет призван в ущерб памяти экономить время (это по сути кеш).
Почему так? Потому что медленны сайт приносит ущерб бизнесу, сайт который потребляет для отрисовки страницы 10 или 20 МБ памяти не нанесет вреда, т.к. даже самый дешевый хостинг за $3 позволяет использовать до 512Мб памяти (даже чтобы иметь запас в два раза, можно использовать до 256Мб). Другой вопрос, что слишком большое потребление памяти может снова тики негативно повлиять на время, тут уже нужно выдержать "золотую середину". Но само по себе потребление памяти "увеличилось на 2-5-10%" это не есть плохо. Это конечно и не то, чем хотелось бы похвастаться, но и не плохо. По моему мнению вы зря на этом делаете такой большой акцент.
Но еще раз, с выгрузками там было справедливое замечание, но здесь же я не вижу какой-то проблемы в самом увеличении потребления памяти на 10%.
Так я неоднократно на форуме акцентировал внимание что анализ и сбор метрик производим через blackfire (https://blackfire.io), также замечу что анализ периодически повторяется. Сравнивать с двойкой думаю не корректно, потому как по большому счету двойка написана в процедурном стиле (хотя там и есть new ...) но это не ООП подход. Вдаваться в дискуссию что лучше ООП или процедурка думаю выходит за рамки данного форума. Для тройки мы приняли решение писать её на ООП. Да, согласен что ООП подход сам по себе уже более ресурсозатратный по сравнению с процедуркой, но у него также не мало плюсов...
Также скажу что на экономию времени выполнения скрипта мы делали и будем делать достаточно большой упор, а вот на экономию памяти вторично. Это не касается ситуаций когда в выгрузках обнаружилось чрезмерное потребление памяти (там были гигабайты), такие моменты естественно будут правиться.
Также в будущих версиях будет добавлен некий функционал, который будет призван в ущерб памяти экономить время (это по сути кеш).
Почему так? Потому что медленны сайт приносит ущерб бизнесу, сайт который потребляет для отрисовки страницы 10 или 20 МБ памяти не нанесет вреда, т.к. даже самый дешевый хостинг за $3 позволяет использовать до 512Мб памяти (даже чтобы иметь запас в два раза, можно использовать до 256Мб). Другой вопрос, что слишком большое потребление памяти может снова тики негативно повлиять на время, тут уже нужно выдержать "золотую середину". Но само по себе потребление памяти "увеличилось на 2-5-10%" это не есть плохо. Это конечно и не то, чем хотелось бы похвастаться, но и не плохо. По моему мнению вы зря на этом делаете такой большой акцент.
Но еще раз, с выгрузками там было справедливое замечание, но здесь же я не вижу какой-то проблемы в самом увеличении потребления памяти на 10%.
Всё сказанное мной, является лично моим мнением, и не является официальной позицией OkayCMS