Как стать автором
Обновить

Комментарии 22

Мне кажется, если использовать в меджике
 $Image1->resizeImage($new_width, $new_height, FILTER_POINT, 1);

в место
 $Image1->scaleImage($new_width, $new_height);

Будут другие цифры
Я сделал еще один вариант теста, в котором используется ваш вариант. resizeImage() работает где-то на 5% быстрее scaleImage(), но в рамках всего теста разница будет не очень заметна.
Вот дополненная версия теста и его результаты: https://github.com/pryazhnikov/php-image-processing-tests/tree/im_resize_vs_scale
Вы не сталкивались с проблемой блокирования запросов из за сессии? к примеру у вас генерится два бейджа от одного человека и они будут вынуждены встать в очередь. Отсюда провал в производительности из-за предотвращения race condition.
konrness.com/php5/how-to-prevent-blocking-php-requests

С арабским везде засада, особенно при отладке в коде с арабским текстом, там такие сюрпризы с непривычки :-) А фотошоп до сих пор бывает глючит.
Какие сессии на отдельном сервере, который с пользователями не работает?
Я полагаю, там запросы от роботов соцсетей, которые никак не могут быть авторизованы на серверах генерации таких бейджей.
Если опустить уже упомянутое про отсутствие там авторизованных пользователей — вы что, правда думаете, что в проектах масштаба Badoo используются сессии на файлах? :)
заставил кого-то улыбнутся… день прошел не зря…
ну сессии в памяти вполне тоже могут запросы тормозить. тут все зависит от механизма работы с ними. Но сессии не всегда нужно использовать, что здесь собственно и происходит :)
У стандартных сессий в мемкеше другая проблема — они неконсистентны: сохранение может затереть параллельно сделанные изменения.

Я делал через CAS, при чтении запоминается casToken, запись, если упрощать — как-то так:

https://gist.github.com/anonymous/141fea5a0ec9d3ed9697

(Понятно, что в данном кейсе сессии ни к чему — я вообще).
Вам правильно ответили — мы используем сессии не в файлах, а в памяти. Технически они доступны на серверах, где происходит генерация изображений, но только если запрос послал пользователь. У ботов нет доступа к данным из этой сессии, поэтому нельзя на неё полагаться и нужно передавать все необходимые параметры в URL бейджа.

Арабский еще очень тяжело отлаживать — его почти никто не знает и после внесения правок непонятно, правильно они работают или нет. Приходилось после любого изменения готовить примеры картинок, отправлять их переводчикам и ждать от них обратной связи :-)
Сделал PullRequest автору с gmagick. Но по факту разница не такая уж и большая. В чем то чуть быстрее, в чем то медленней. Создание и сохранение чуть медленней, операции чуть быстрее, некоторые заметно быстрее. но на итоговый результат повлияет не так уж сильно. Leptonica похоже получается быстрее, просто разница выходит где то в 1.5 а не в два раза.
К сожалению, я пока не могу прогнать ваш тест — под рукой нет сервера, где одновременно были бы и leptonica, и gmagick.

В момент поиска графической библиотеки тесты показывали, что leptonica быстрее даже не в 2 раза, а процентов на 25. Было это давно и я не смог найти ни исходников тестов, ни их точных результатов, поэтому сделал новый тест просто чтобы показать (а заодно и самому понять), на каких конкретно операциях leptonica работает быстрее. Я думаю, что тут tony2001 сможет сказать больше меня.
возможно тесты были по сишным версиям библиотек, а обертки сделали свое дело?

а можно ли где нибудь найти используемую в тестах обертку для leptonica? чтобы попробовать тесты погонять?
Касательно сохранения, немного ускорить сохранение ImageMagick'ом можно если заменить
    $Image2->writeImage($output_file);

на
    file_put_contents($output_file, $Image2);

да, кажется немного странным. Выигрыш получается порядка 10% где то. Мелочь конечно. Но так как это самая долгая операция получается. То лучше чем ничего :)
Кстати, может кто просветить касательно японской локализации. У них же вроде раньше было распространенно вертикальное письмо. С распространением компьютеров тренд поменялся, и сейчас вроде почти нигде не используется, или я не прав, и вам приходилось подбирать шрифты, и разбивать тексты с учетом вертикальных, а не только горизонтальных ограничений?
Мы выводим тексты на японском слева направо, так что с этой точки зрения особенностей нет. Проблемы там скорее с разбиением на строки — нет классических пробелов и нельзя разбивать на произвольном месте, чтобы случайно не порвать слово, состоящее из нескольких символов. У меня было пару мыслей на этот счёт, но на практике их реализовывать не пришлось — у нас тексты на японском достаточно короткие и в итоге переводчики просто укоротили 1-2 лексемы, которые не помещались в одну строку.
Проблемы там скорее с разбиением на строки — нет классических пробелов и нельзя разбивать на произвольном месте,
В интернете говорят что Maximum Matching — стандартный алгоритм для разбиения японских текстов на слова. В этой лекции class.coursera.org/nlp/lecture/127 где-то с 10-ой минуты про него рассказывают. Но там нужен словарь японских слов.
Как вариант я хотел использовать специальный разделитель в лексемах (например, __EOL__), который бы переводчики добавляли в места возможного разбиения тексов на «сложных» языках. При генерации бейджа код бы либо “выкусывал” его (в случае когда текст помещается в одну строку), либо вставлял на его месте перенос строки. Это бы потребовало ручной работы, но совсем немного, ведь используется всего два-три десятка лексем.

Из очевидных «граблей» — опечатки у переводчиков при вводе спецсимволов, но их можно ловить автоматически: в лексемах с опечатками после разбиения на строки будут символы из двух классов: иероглифов и латиницы, чего в корректных лексемах быть не должно.
У ImageMagick и GraphicsMagick есть затыки с многопоточностью при работе с одним файлом.
Каковы результаты с MAGICK_THREAD_LIMIT=1 OMP_THREAD_LIMIT=1 php…
(или Imagick::setResourceLimit (imagick::RESOURCETYPE_THREAD, 1); )
Проверил на локальной машине, результаты вышли на уровне погрешности. Поэтому решил проверить, imagick скомпилирован уже с нужным параметром. Увеличил количество потоков. Появился затык на операции вращения, где то раза в два. в остальном +-5% что по сути сопоставимо с погрешностью.

Правда отсутствие нормальной обертки для leptonica мешает полноценно повторить тесты. Можно сколько угодно подкручивать тесты imagick/gmagick но их не с чем сравнивать. Надо будет попробовать старую версию, которая есть в паблике, и сравнить разницу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий