Производительность vs удобство интерфейса

На выходных я добавил к своему игрушечному браузеру поддержку контента записанного прямо в страницу, то есть вида когда источником ставится data:image/png..... При этом заменил способ работы с файловой системой на использование gio. Это стандартный компонент в новых версиях glib для доступа к ресурсам и при установке в систему плагин позволяющий в зависимости от плагинов работать с файлами (file:) и сетью (http:,smb:,https:) через унифицированный интерфейс и все типы контента отображаются одинаково для программы.

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

• что реализации плагина для data:... я не искал - текущая реализация как по мне вполне сгодиться;
• а вот для http использовать реализацию плагина по умолчанию нельзя так у меня есть хоть частичная реализация работы с cookies(очень плохая: просто объединение всех cookies полученных за сесию в одну строку и отсылку на все страницы);
• и что более важно отсутствие логики работы с относительными путями для случаев не файл(по коду все относительные пути берутся начиная с пути места запуска приложения) - и как результат я использую свою реализации обработки относительных путей - пока неверную, но надеюсь когда нибудь доделаю.

Благодаря реализации интерфейса доступа к ресурсам основанном на создании потоков потерялась возможность использовать возможность системы отображать файлы в память. Отображать то можно, но смысла мало, так как в вызовах используется указание области памяти куда нужно сохранить и потом можно спокойно вызвать освобождение. При этом, если нам удалось отобразить файл на какую-то область мы должны(в зависимости от реализации) вызвать unmap перед освобождением участка. Хотя в linuх - может сработать: Normally, malloc() allocates memory from the heap, and adjusts the size of the heap as required, using sbrk(2). When allocating blocks of memory larger than MMAP_THRESHOLD bytes, the glibc malloc() implementation allocates the memory as a private anonymous mapping using mmap(2). Но лучше не играться с этим.

Если использовать после отображения копирование данных - то мы получим стандартные вариант read,write - и увеличения производительности не будет.

В glib есть обертка над mmap - gmappedfile, но mmap используеться только для MIMEINFO - xdgmimecache.c

Пока абстракция интерфейса побеждает.

PS: Хотя в общем тенденция хорошая - мало приложений использует отображение, и еще меньшему количеству он реально нужен. А так мы получаем простой унифицированы интерфейс доступа.