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

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

Круто что картинки сжимаются, и экономят при этом ресурсы, но но в чём проблема их потом отображать нормально? Постоянно по 10+ секунд грузятся, нажимаешь на картинку, не можешь вытерпеть и тыкаешь «открыть оригинал», чтоб посмотреть её в браузере. И в браузере она открывается быстрее, чем в дискорде догружается уменьшенная превьюшка.

Я понимаю что это перевод, но как же странно выглядят такие статьи про скорость и крутые решения, когда у тебя в открытом дискорде картинки чуть грузятся…
Попробуете расширение Imagus, оно по ссылкам показывает картинку. Обычно получается шустрее.

Также использовали go + openCV для ресайза картинок и объемы схожие.
Вы не рассматривали вариант openCV + gpu?

А может без Go можно было обойтись? OpenCv + libuv?
НЛО прилетело и опубликовало эту надпись здесь
Пробовали. Можно.
Но есть один довод за go — удобно балансировать нагрузку при обработке картинок. Хорошая конкурентная модель позволяет равномерно нагружать сервер.
В итоге получилось лучше и программисты писали быстрее. в
Почему бы просто не сжимать/ресайзить картинки на клиентской стороне?
То что сразу приходит на ум — увеличение времени загрузки страниц. Для интернет-магазина с >10000 товаров я бы точно не стал такое делать.
Дискорд — это чат, где пользователи могут загружать картинки. В моем предложении отправитель загружает пожатую + оригинал. Интернет-магазин тут не при чём.

В таком случае будет легко подменить превью.

Что мешало использовать Сишный код из pillow?

Привет, разработчик Pillow-SIMD с вами.


Очень жаль, что я не видел ни оригинальную статью, ни перевод год назад. Нашел её несколько дней назад совершенно случайно. Ну что ж, тем интереснее посмотреть, что стало через год.


lilliput работал не хуже или лучше, чем pillow-simd в тех задачах, которые нам нужны.

Я проверил бенчмарки и пришел к неутешительным для компании Discord выводам:


  • За год производительность Pillow-SIMD только выросла
  • В тестах (а может быть и в продакшене) были использованы более качественные и затратные фильтры, чем удовлетворяли компанию Discord
  • В тест, будто намеренно, вставлены лишние операции для Pillow-SIMD, которые не только впустую тратят время, но и изменяют изображение так, чтобы его было сложнее кодировать (добавляют альфаканал)
  • За год производительность Lilliput при работе в webp сильно деградировала. Это заметил не только я
  • Конкретно этот кейс (кроп+ресайз) можно еще больше оптимизировать в Pillow-SIMD, получив в итоге скорость для джипегов на 77% быстрее, чем у Лилипута
  • Мало относится к бенчмарку, но все же: В Pillow-SIMD есть возможность загружать джипеги сразу меньшего размера, чем они есть в файле. Это может очень сильно экономить память и время. В OpenCV такой возможности нет

Все неточности и странности в бенмарке я поправил и оформил в виде пулреквестов. Ну а чтобы самим все не собирать, вы можете сразу воспользоваться моей починенной версией.


Media Proxy требовал на 60% меньше серверных инстансов для обработки такого же количества запросов, что и Image Proxy, выполняя эти запросы в гораздо меньшие разбросы времени.

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


Что в итоге: компания Discord написала собственную библиотеку и поддерживает свой форк OpenCV, чтобы это всё работало хуже, чем если бы они просто поправили пару строчек на Питоне.


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

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.