Простое решение для обработки изображений на лету с кешированием результата

[@Shvonder]

Интересно насколько отличается по скорости проверка существования файла через file_exists и %{SCRIPT_FILENAME} !-f

[@L3n1n]

Если Вы о file_exists который в php то тут и сравнивать не нужно.
Проверка на уровне веб сервера и проверка с запуском php. Вроде как само должно говорить за себя.

[@Shvonder]

Я имею ввиду выполнение самой функции, не учитывая запуск php

[@Shvonder]

Я думаю, это больше зависит от скорости файловой системы (размера кеша и т.д.). Просто по-моему в этом решении экономия по скорости не настолько ощутима, что бы применять эти непонятные файлы конфигов и настройки сервера. Почему бы не создавать миниатюры на этапе обработки шаблона?

[@esvit]

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

[@homm]

Что позволит вам «не учитывать запуск php»? На это реально уйдет на порядок или два больше времени, чем на саму проверку.

[@Shvonder]

Ну так страницу же php и создает. он в любом случае запускается. Может вы просто не совсем поняли мою мысль. Я хотел бы понять насколько будет дольше работать иной алгоритм и есть ли смысл вообще делать так как автор.

То что я имел ввиду:
В шаблоне пишем {{ image|thumb(«200x200», { «watermark»: «right bottom», «grayscale»: true }) }} (это пример из статьи)
На основе этих параметров обработчик создает хеш (можно приплюсовать timestamp для гарантированной уникальности). Получается имя файла превью. Если этого файла не существует (вот тут проверка file_exists), он создается. При следующем выводе этого файла ничего создаваться не будет, а просто подставится хеш в src. Клиент же получает ссылку на уже готовый созданный файл и пропадает необходимость в доп настройках сервера.

Конечно, загрузка сайта будет медленнее при появлении новых картинок, но только один раз и только у того пользователя кто первым загружает страницу с новыми картинками. А на сайтах где картинки добавляются массово и нагрузки огромные, ни мой, ни автора вариант не прокатит. Там либо превью создается еще на этапе загрузки картинки, либо php вообще не участвует в этом.

[@homm]

Действительно, не так понял. Как вы предлагаете, тоже имеет право на жизнь и реализация в целом будет проще. Но вы правильно описали минусы: при большом кол-ве картинок пользователь увидит страницу немного позже.

[@L3n1n]

/static/d1/7e/d17e248758722c42d8c88d21d8b538d7.jpg

Не маловато ли будет 2х уровневой структуры? У меня /d/1/7/d17e248758722c42d8c88d21d8b538d7.jpg и некоторые папки имеют больше сотен файлов. Хотя тут конечно от проекта зависит.

[@homm]

У вас файлы раскиданы по 16^3 папкам, у esvit по 16^4. Уровень влажности не причем.

[@L3n1n]

Точно. Спасибо. От уровня зависит только количество папок в папке. У меня оно 16 у автора 16^2.

[@artishok]

Было бы странно, если бы уровень влажности влиял на размещение файлов.

[@tytar]

Прошу прощение за глупый вопрос, ибо темень я деревенская.
В коде на гитхабе есть запись

function thumb($image, $size, $options = [])

И собственно вопрос

$options = []

что это за запись. Ведь php 5.3.25 выдает ошибку
Parse error: syntax error, unexpected '[' in

[@esvit]

Это php 5.4, короткое объявление массива, '[]' это аналогия 'array()' на php 5.3