С помощью phpThumb выполняется генерация 8 jpeg-миниатюр разных разрешений (без crop'а - только масштабирование с сохранением пропорций ). Исходные изображения весят 5-8 Мб. Если выполнять генерацию в лоб (без всяких оптимизаций) - времени уходит 11-15 сек на одно изображение. Неприемлемый вариант.

Здесь возможны 2 оптимизации:

1. Генерация превью начинается с самой большой из них. Далее для каждой генерируемой миниатюры в качестве исходного файла берётся предыдущая сгенерированная миниатюра. В этом случае время обработки одного изображения сокращается до 2,5 сек. Уже лучше.

Вопрос 1. В этом случае не пострадает ли качество генерируемых миниатюр ? Или разницы заметно практически не будет ? (на тестовом изображении разницы не заметил, как будет на остальных - не знаю)

2. Для генерации всех миниатюр используется один объект phpThumb. Но проблема здесь в том, что метод phpThumb::GenerateThumbnail() после генерации миниатюры удаляет (освобождает) ресурс, соответствующий исходному изображению (это поле gdimg_source ). Соответственно, при генерации следующей миниатюры тем же экземпляром объекта phpThumb , ресурс исходного изображение снова будет сгенерирован из файла (затратная по времени операция).

Можно перегрузить метод phpThumb::GenerateThumbnail() , но это не лучший вариант, т.к. придётся дублировать много оригинального кода. И при каждом обновлении библиотеки phpThumb этот перегруженный метод также придётся обновлять.

Вопрос 2. Как без перегрузки метода phpThumb::GenerateThumbnail() заставить phpThumb не освобождать ресурс исходного изображения ?

авторпочему-же. ...это не лучший вариант, т.к. придётся дублировать много оригинального кода . И при каждом обновлении библиотеки phpThumb этот перегруженный метод также придётся обновлять.

Собственно, это проблема организации кода оригинальной библиотеки. Всё в куче. Перегрузка метода phpThumb::GenerateThumbnail() породит сильную зависимость своего метода (перегружаемого оригинальный) от оригинальных исходных кодов этого метода.

автор 1. Генерация превью начинается с самой большой из них. Далее для каждой генерируемой миниатюры в качестве исходного файла берётся предыдущая сгенерированная миниатюра. В этом случае время обработки одного изображения сокращается до 2,5 сек. Уже лучше.

Вопрос 1. В этом случае не пострадает ли качество генерируемых миниатюр ?
Вот на этот вопрос каким будет ответ ?

авторо каких размерах вообще идет речь? исходного и копий?Исходное - 5-8 Мб (4800 х 3600 и выше), миниатюры - от 30х30 до 1000х1000 px.

авторесли исходное большое, а миниатюры совсем мелкие, то вначале можно уменьшить его с пом. imagecopyresized . она быстрая. а далее уже делать миниатюры с пом. imagecopyresampled
, ибо она медленнее т.к. еще есть сглаживание.В этом случае придётся создавать один дополнительный служебный (уменьшенный относительно оригинала) экземпляр изображения в качестве базового для создания миниатюр. Но можно в качестве такого базового взять самую крупную из миниатюр (и создавать её нужно будет со сглаживанием, т.к. это рабочая миниатюра). В этом случае "лишних" экземпляров изображения создавать не придётся. Либо, как я написал выше, для каждой миниатюры в качестве базовой брать предыдущую созданную (на один шаг большего размера).

Здесь вопрос скорее в том, будет ли миниатюра, созданная из сглаженного изображения (imagecopyresampled ), худшего качества, нежели миниатюра, созданная из несглаженного изображения ( imagecopyresized ).

авторили если все это так критично, вообще отказаться от GD в пользу ImageMagick какогонить
ибо кардинально тут мало что можно сделать (с phpThumb). только мучительно оттягивать момент ухода от нее. раз уже щас неустраивает скорость.Насколько я знаю, phpThumb как раз и использует функции библиотек GD и ImageMagick. Самостоятельно он изображения не обрабатывает. И по возможности использует ImageMagick (если установлен и настроен), если нет - GD. Вроде так. Тогда отказ от phpThumb выглядит абсурдным и может быть целесообразным только если использовать иные (более быстрые) библиотеки, нежели GD и ImageMagick.