900-1000 это реальный, который есть на данный момент, судя по описанию zval, на моих данных ожидаемое потребление 200-250 байт на один обьект, куда пхп тратит столько памяти я не могу и предположить. очень большой оверхед.
> Похоже тут проблема. Это скорее всего garbage collector барахлит.
В массив добавляются новые элементы, ничего странного в том что растет количество используемой памяти при этом.
> Попробуйте замерять потребление памяти на тестовой выборке
Мерял, мерял, 900-1000 байт на каждый stdClass описанной структуры. xdebug все тоже красиво показывает.
Я помню у нас в каком-то топике уже был спор на эту тему) Конечно, можно критические места и на сях написать, но это единоразовая задача, которая раз в сутки стартует и выполняется около 5 мин. Я никогда не буду увеличивать бюджет на переписывание этого места на чем-то более подходящем.
Про curl я не упоминал. Падает на обычном таком коде… 2гб не хватает, зато лимит в 9 норм. Линейное увеличение размера на каждую вставку в массив, на 900-1000 байт.
Потому что в голову девелоперам php пришла идиотская мысль сравнивать числовые строки как целочисленные значения. Чем руководствовались при принятии этого решения — загадка.
Посмотрел ман, ман говорит, что числовые строки сравниваются как целые числа. Я вот раньше не задумывался об этом, но сколько кода подвержено такой потенциальной ошибке?
от себя еще добавлю. когда сфинкс возвращает 1000 id, а отображение на странице лишь 20, то ORDER BY FIELD единственный выход. к тому же, не забывайте, что и так максимально оптимизированная сортировка самим mysql будет в разы превышать по скорости самописный код на php который слепит массив id от сфинкса с результатами из БД.
