Я как-то в своё время решил заюзать stb_image для загрузки картинок в движке, ибо он был быстрый, а ещё - легко встраивался в приложение, без страшной возни с зависимостями, условными autoconf и прочим. И в какой-то момент немного поправили в pro.graphon: вот, дескать, libpng быстрее. Беглый поиск привёл меня к тесту, и сомнения стали смущать: а что, если, правда, быстрее? Не пора ли съехать? Забегая вперёд, я хочу отметить сноску в этом посте, где автор пишет, что на малых PNG, у него stb иногда и выигрывал по перфу. И это почти мой случай - у меня нагрузка состоит из POT текстур от 512px до 2048px.
В итоге собрал тест из двух вариантов - оригинальный загрузчик , и модификация для libPNG, которая была собрана мной на основе гиста . Для нагрузки теста использовалась загрузка базовых текстур в hrtp-demake на старте игры. Также в замер попала загрузка пары конфигурационных файлов - но они грузятся быстро и особо тест не замедляют.
Тестировал на двух конфигурациях: мощной - HDD, i5-9400F, 40 Гб RAM, GeForce 1050Ti, Win 10 и слабый ноутбук - SSD, Intel N3710 1.6 GHz, 4 Гб RAM, Intel HD, Win 10 . Из компиляторов - использовались MSVC 2017 и GCC 12.2.0 . Для GCC результаты немного смещены в дебаге в сторону libPNG, так как она в обоих случаях собрана в релизе. Собственно, результаты замеров приведены по ссылке.
В целом результаты странные - в случае MSVC на обоих конфигурациях libPNG проиграла stb, а на GCC - на слабой конфигурации немного выиграла. Я подозреваю, что можно оптимизировать загрузку через libPNG получше, но ничего умного в голову не приходит, кроме может сразу отдавать здоровенный 4k х 4k блок пикселей и потом его как-то размечать. Но выглядит костылём. Учитывая, что результаты лежат друг от друга недалеко - пожалуй, останусь на stb.
Комментариев нет:
Отправить комментарий