А кроме комментариев есть ещё примеры?

pdoTools появился не на пустом месте, а потому что я делал разные сложные сайты, включая bezumkin.ru

К самому тесту замечания есть?

Ты даже кода чанков не привёл, тупо итоговые цифры и заявление, что разницы нет.

Если ты эти тесты проводил на одном сайте, и парсер pdoTools был включен — то поздравляю, ты уже пользовался оптимизациями, потому что pdoParser разбирает простые плейсхолдеры сам, без modTag.

Я прямо сейчас создал 2 сайта на modhost.pro. На один установил pdoTools, а на другой нет.

Тестовый сниппет:

<?php
$items = [];
for ($i = 1; $i < 10000; $i++) {
  $data = ['id' => rand(), 'pagetitle' => 'page' . rand()];
  $items[] = $modx->getChunk('test', $data);
}

$output = number_format(microtime(true) - $modx->startTime, 4) . "\n";
$output .= number_format(memory_get_usage() / 1048576, 4) . "mb\n";
$output .= implode("\n", $items);

return $output;

Простейший чанк:

<p>[[+id]] - [[+pagetitle]] [[+id:is=`10`:then=`1`:else=``]]</p>

Обрати внимание, что чанк без Fenom, чисто синтаксис MODX.

Смотрим на 10000 проходов, чтобы разницу было хорошо видно:

— MODX без pdoTools — 1.3216 сек (самый быстрый результат, что удалось увидеть)
— MODX c установленным pdoTools — 0.0557 (самый тормозной результат, было и 0.0156).

Внимание, pdoTools просто установлен, и работает по умолчанию. Никаких специальных оптимизаций.

Теперь понятно, что парсер MODX без pdoTools просто тормозное говно и твои тесты ни о чём?



Updated 26.04.2022
Попробовал повторить тест еще раз и не смог — оказалось, что я допустил ошибку. Если сниппет использует $modx->getChunk(), то разницы в скорости не будет, потому что pdoParser тогда не работает.

Сниппет должен использовать $modx->getService('pdoTools')->getChunk('test', $data);, тогда всё быстро.

Всё проверил еще раз и накатал новую заметку с результатами.

Замечание принял. А кроме комментариев есть ещё примеры?

Или это только про удобство, а не скорость?

К самому тесту замечания есть? Я говорю про тест через сниппет в обычном режиме, в котором будут работать 99,9% разработчиков, а не через API.

П.С. Лично я считаю, что эти тесты искуссвенные. В боевом проекте, где куча чанков, сниппетов и т.д., цифры будут совершенно другие. Вот где интересно было бы погонять тесты.Но судя по отзывам разработчиков, которые меняли синтаксис, разницы особо не видно. Даже часто феном немного проседал.

да, вот так работает. спасибо.

Вспомнился роман Хейли «Колесо». Там создавали новую модель машины и на этапе тестирования возникла проблема — что-то с коробкой передач на определённой скорости. Стоимость доработки 5 долларов. Ерунда. Копейки по сравнению со стоимостью машины. Но разработчики отказались от этой идеи. Причина — планировалось выпустить около 1 миллиона экземпляров. А значит дополнительный расходы составили бы + 5 млн. долларов.

10 лишних запросов для небольшого сайта — плёвое дело. А для высоконагруженного может оказаться непозволительной роскошью.

Подход к кэшированию должен быть вдумчивым. Кэшировать всё подряд также не имеет смысла. Нужно думать об актуализации данных. Поэтому всегда нужно находить баланс. Для этого и нужны опытные разработчики. )

Даже 100 ресурсов — это большая редкость.

Я тебе привожу пример, что нет — не редкость.

Как справится парсер MODX с выводом такой ветки комментариев, если он каждый тэг и условие будет превращать в modTag и запускать его parse?

PHP шаблонизатор всё еще только про удобство, а не скорость?

Читаем внимательно и до конца.

Вот в этой заметке сейчас 890 комментариев и она выводится плюс-минус за 1 секунду на Fenom с разными условиями.

Выводится без кэша, потому что комментарии отличаются для каждого юзера. Админу выводятся удалённые, автору подсвечиваются его ответы и т.д.

Попробуйте это повторить на парсере MODX. Не думаю, что вывод комментариев на сайте это прям такая уж редкая задача.

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

Error 42S22 executing statement: 
Array
(
    [0] => 42S22
    [1] => 1054
    [2] => Unknown column 'modResource.vznos' in 'where clause'
)

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

Прочитал про размер кэша. Твоё удивление от непонимания. Что такое кэш? Это статичные данные. Если у тебя кэш на феноме в 10 раз меньше, то есть повод задуматься — всё ли закэшировалось? Отсюда и лишние запросы к БД. Конструкция {include 'чанк'} никогда не кэширует чанк.

Просто с таким же успехом можно восхищаться пустой папкой кэша после того, как ты его отключишь.

Наверно поиском [[$ по таблицам контента, шаблонов и чанков. Или заюзать событие OnParse.

Точных сроков дать не могу. Как появится свободное время.

Насколько помню есть параметр tvPrefix и он по умолчанию равеy 'tv.' Попробуйте указать

$params['tvPrefix'] = '';

есть там некоторые ограничения из-за LEFT JOIN при includeTVs
а у вас не правильно, тут полюбас будет так:

$params['where'] = ['pagetitle'=> $stag];

и сделайте если под админом

$params['showLog'] = 1;

и return на время теста отключите

Да, проблема была в хостинге.

Ну не знаю, я бы наверное вообще отказался от вызова сниппета в своём сниппите.

Весь код там большой, 4 аналогичные выборки и обработка полученных данных. В 3-х из них этот TV параметр у родителя, поэтому я вынужден получать его через дополнительный запрос, а в этом случае этот параметр есть у самого ресурса.
И еще смущает что когда я его выбираю как он называется (vznos), то страница наглухо падает от 500 ошибки, а если как tv.vznos то ошибки нет, код работает корректно, кроме того что в полученном json массиве нет нужного TV параметра.

А весь код покажи.

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

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