Открыл в Gwenview каталог с лоровскими пикчами (13287 изображений, вес 6,2 ГБ). Gwenview начал жрать 2 потока процессора и оперативку под генерацию миниатюр.
Потом оперативка кончилась и система зависла, т.к. свопа нет. я не стал ждать развязки и нажал резет.
В итоге Gwenview, полностью сгенерировав миниатюры, занял 9,5 ГБ оперативки.
Я не эксперт в разработке программ, но по-моему, так не должно быть.
свопа нет
Если без мата: ты не прав.
Да я знаю, но у меня на том SSD, где своп был, теперь винда стоит)
Может тебе zram включить?
Что-то не хочется)
При повторном запуске каталог открывается быстрее, но если мгновенно промотать на несколько сотен файлов - опять тормоза, жор процессора и гигабайты оперативки.
Это баг конечно, посмотри в багтрекере у них, может ты не первый жалуешься
Я бы не назвал это багом. Всё-таки 13200 скриншотов, 6,1 ГБ. Это, скорее, изъян проектирования.
По-твоему, как можно решить эту проблему? Создавать миниатюры пониженного качества?
Ты мне для начала объясни, как 6 гигов фоток на диске могло создать 9 гигов миниатюр в ОЗУ… Ну да, на диске они сжаты, а в памяти наверное нет, но блять неужели мелкость миниатюр не компенсирует этот коэффициент? Получается, что миниатюра в памяти занимает больше полноценной фотки на диске?
Да, тоже хороший вопрос
как 6 гигов фоток на диске могло создать 9 гигов миниатюр в ОЗУ…
На диске скомпрессированы, в ОЗУ/VRAM распакованные?
Много ты сожмёшь в файлах jpeg и png?
Так сравни размер в png/jpeg и в bmp/raw.
Ну из данных выше уже понятно, что миниатюры на диске 2 Гб, а в оперативной памяти 9, грубо говоря в 4 раза они распухают.
Всё равно такое потребление рамы это баг, возможно ещё не заведённый
Я не про разбухание в ОЗУ, я про сравнение форматов как таковых.
RAW/BMP это просто таблица цветов пикселей, его размер не зависит от сложности картинки, а только от размера и глубины цвета.
И белый шум, и заливка одним чистым цветом будет иметь одинаковые размеры, именно в таком виде в конце картинки и будут в ОЗУ.И белый шум, и заливка одним чистым цветом будет иметь одинаковые размеры, именно в таком виде в конце картинки и будут в ОЗУ.
именно поэтому их там быть и не должно
По-твоему, как можно решить эту проблему?
Не поверишь, я сейчас как раз ебусь с похожей задачей на работе… Ну, идейно похожей. Много однотипны объектов занимают “дорогой” ресурс, надо уменьшить футпринт, при этом не потеряв в скорости
Решение всегда одно и то же. Не надо держать в памяти все 13000 миниатюр. Они ведь не нужны все сразу, а только те, что отображаются на экране – ну и наверное ещё парочка экранов вперёд и назад, для упреждения. Код gwenview и KDE я не знаю, я другой программист
Да, это явно в Gwenview что-то с алгоритмами намудили
При повторном запуске каталог открывается быстрее
Ну вот, значит в кэш он умеет, в каком-то виде… Уже нагенерил эти 13000 миниатюр и они где-то лежат у тебя на диске. Скорее всего, на диске они не 9 гигабайт занимают, но ты проверь :)
А зачем он весь этот кэш грузит в RAM для 13000 файлов… Как я уже говорил, надо багтрекер смотреть
Я так понимаю, вот миниатюры Gwenview
А у меня на гноме 3 не показываются превьюшки для фоток > 10 Мб (в файловом менеджере, nautilus)
Когда я гуглил проблему, этот лимит как-то не удалось по-быстрому изменить, типа глубоко зашит, в итоге я забил тогда, так как таких фоток было ну 10% от общего числа. Но всё же периодически попадаются
Да, такой ход бывает используют, чтобы не было как у Gwenview. В Dolphin тоже можно лимит размера файла включить.
В настройках Gwenview есть режим пониженного потребления ресурсов, но я не увидел разницы)
Я ща открою этот каталог в Dolphin и миниатюры включу)
Лол, зацените разницу))
И никакого жора процессора не было
Миниатюры на вид выглядят одинаково
запускает другой линуксовый софт
Лол, зацените разницу))
Т.е. проблема не в линуксовом софте, а в конкретном линуксовом софте от конкретных идиотов разрабов?
Я не эксперт в разработке программ, но по-моему, так не должно быть.
А это из той же оперы, про которую писал @crypt. Современные погромисты идиоты чуть более, чем все. Сначала дерадируют инструменты, которые создают сами программисты, а потом деградирует поколение программистов, которые использую деградировавшие инструменты. Чему тут удивляться?
