По скрипту импорта-экспорта - Импорт-экспорт данных

Писал скрипт импорта, в котором использовал методы из самого JoomShopping'a
В частности, для сохранения категорий брал метод save(), из JshoppingModelCategories
Метод getPrepareDataSave переопределял по-своему.
После получения ожидаемого результата - решил прогнать "профиляркой" (встроенным в Joomla отладчиком, т.к. xdebug лень настроить). И тут "прифигел"
Мне нужно получать конфиг JSH - я его дёргаю через JSFactory::getConfig()
А в отладчике запрос
который выполняетс 5.16 мсек
Дальше
на 4,5 мсек (я к товарам не обращаюсь! это всё getConfig!)
Ну и дальше на любой "чих" выполняется сначала SHOW FULL COLUMNS , а потом уже SELECT

Вот у меня и возникает логичный вопрос. Это чтож получается, что зря я вязался к методам JSH, которые проверяют всё на свете, перед тем как выборку из базы сделать?
Проще было свои запросы к базе, напрямую, писать, чтоб миновать постоянные вызовы JSFactory::getTable?
Или я не понимаю все важности получения столбцов перед выборкой? Перед записью ещё могу понять, но перед выборкой то зачем?

Ещё есть "проверяльщик" сортировок, если в SAVE передавать 'ordering'
190 категорий - 13 сек

Или я не понимаю все важности получения столбцов перед выборкой? Перед записью ещё могу понять, но перед выборкой то зачем?

нет разницы когда, если мы работаем с JTable, то они нужны всегда, и получаются при инициализации. вообще конечно я согласен что разработчики немного странно решили с этими таблицами, и дергают их вместо моделей. но конкретно в отношении импорта - то какая разница? если вы действуете нативными методами Joomla, то все равно таблицы рано или поздно дернутся, и SHOW FULL COLUMNS выполнится. это ж синглтон, выполнится один раз и все. либо как вы и сказали вообще отказаться от табличных методов Joomla. но вот почему этот запрос выполняется у вас 5 секунд - это вопрос.... он вообще должен выполнятся мгновенно, вы точно ничего не путаете? если заглянуть в исходники, то можно увидеть что это даже не запрос по сути, а просто вывод заголовков таблиц, просто вывели уже готовую информацию. временных затрат вообще никаких, все время уходит в общем то только на обращение к базе и на получение ответа. у вас может база удаленно, и поэтому такой ответ долгий?

вы точно ничего не путаете?

Очепятка была. Там не сек, а миллисек. Всего 15 таблиц дёргаются таким образом (75мс или, почти, 0,1с). И каждая ~5миллисекунд. Выглядит не радужно, на фоне остальных запросов в 0,03 - 0,05 миллисекунд.

Выглядит не радужно, на фоне остальных запросов в 0,03 - 0,05 миллисекунд.

опять путаете?

0,03 - 0,05

Устал! Руки дрожат! 

Нули лишние поставил. 0,3 - 0,5 мс

Сейчас переписал немного логику getPrepareDataSave и вынес отдельно запрос на присвоение родителей.
Получилось, вместо 964 запроса, 405, для добавления 190категорий одним проходом.
Памяти тоже меньше стало. Было 23 - стало 20. Но вот время выполнения SHOW FULL COLUMNS (решил не уходить от джумлового JTable) мне не нравится.
http://joxi.ru/Y2LEQq8tn1kzLA

Бог с ним, со временем. 30 секунд хватает с головой, а в перспективе всёравно на cli переводить планировал
Но вот вылез другой вопрос! http://joxi.ru/a2XGne7IyjNkem
Как избавиться от забивания логом всей памяти? Я на хостинге 1ГБ выделять под это дело не собираюсь! Да и эксперемент показал, что ему и 2 ГБ мало.
Собсно, как отключить логирование запросов к базе, при работе с JTable?

отключить дебаг

Хоть вкл, хоть откл - разницы нет. Чувак на Yii делал импорт и говорит, что тоже лог сжирал все, если через методы ядра в базу лезть.

если дебаг отключен логов нет. логи есть только с отладкой.

если дебаг отключен логов нет. логи есть только с отладкой.

Я даже плагин отладки отключил, но всёравно по памяти падает.

падает там же в /Log/Log.php ?

падает там же в /Log/Log.php ?

Он через раз падает то в Lolg/Log, то в legacy/error

Но что-то меня начинает наталкивать на мысль, что не в этих классах проблема. Память забивается чем-то другим.
Только мне никогда раньше не приходилось профилированием по памяти заниматься. А тут ещё вдруг обнаружил, что xDebug делать это не умеет  .

не подкинете нормальный инструмент профилирования, с мониторингом памяти? а то их как-то много оказалось...

var_dump + memory_get_usage - самый универсальный даже хз что вам сказать... я не наблюдаю у себя какую либо проблему с памятью, даже если загоняю в цикл 20К запросов с JTable... время - да, долго. но по памяти проблем нет.

var_dump + memory_get_usage

Ну вот я этим тоже занимаюсь. Пока понял одно, что после каждого добавления товара + 300кб в память.
Ещё, кажется, понял, что нужно полностью отвязываться от методов джумшоппинга (я всёже не все перетащил на чистый JTable - некоторые методы джумшоповские использую). На мысль натолкнуло то, что падает в legacy/error, а в джумшоппинге очень много обращений именно к JError, который deprecated
Видимо он то и забивает память. Где-то, что-то недопередаю ему.
Буду переделывать products по-своему полностью. Не предназначен жш, для пакетной обработки!

Не предназначен жш, для пакетной обработки!

та все там нормально. в том числе в админке есть пакетное сохранение, и оно работает без нареканий. просто что то вы видимо и правда не учитываете... но тут даже больше вопрос в том, что в импорте в принципе должно быть все свое ибо зачем делать 20К запросов если можно сделать 5 поэтому имхо

Буду переделывать products по-своему полностью.

это очень правильное решение

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

Переписал все методы из products и categories по-своему. Получил результат намного лучше.
Весь каталог одним проходом потребляет 420МБ памяти (190 категорий и 5000 товаров)
Обновление цен для всех товаров - 72 мб.
Обновление остатков - 38мб.
Такие результаты меня устраивают больше.
Пока перепиливал - обратил внимание, что ЖШ использует устаревшие методы до-последнего. Видимо они решили тащить совместимость, пока Joomla совместима. Но сколько же работы им представти, когда уберут всё это добро из Joomla!

Ну и запросы внутри foreachей - это чтото!
Например, отвязка товаров от категорий:
сначала выборка всех связей по id товара
потом foreacheм перебирает каждую категорию из массива и, в теле цыкла, делает запрос на удаление каждой отдельной.
С привязкой к категориям - таже беда. Одна связь - один insert
Ещё не могу понять, почему они так сильно к orderingу цепляются? Везде его тычат и создают кучу дополнительных запросов в базу.

Пока перепиливал - обратил внимание, что ЖШ использует устаревшие методы до-последнего. Видимо они решили тащить совместимость, пока Joomla совместима. Но сколько же работы им представти, когда уберут всё это добро из Joomla!

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

Ещё не могу понять, почему они так сильно к orderingу цепляются? Везде его тычат и создают кучу дополнительных запросов в базу.

а это еще вообще с 1.5

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

повсеместное выполнение запросов методом query, который

deprecated 13.1 (Platform) & 4.0 (CMS)

Формирование алиасов, записи в лог, выброс эксэпшенов и т.п. Всё - deprecated, и в 4.16.3 - это всё присутсвует