Comments 9
Действительно всё настолько плохо с производительностью "обычных" API или, поигравшись с ними (по сути – закэшировав данные и уменьшив количество операций ввода/вывода/, можно достичь той же скорости, что и с memory map (грубо говоря, проблема уровня "не надо читать каждый байт отдельно")?
Всегда считал, что memory maps в основном упрощают жизнь, позволяя избавиться от кучи потенциально содержащего ошибки кода, а не кардинально улучшают производительность.
Системные вызовы это дорого, а block cache и mmap у нас уже есть.
Можно переписать в свою программу жирный кусок ядра линукса, параллельно потеряв все плюсы системного управления памятью, но зачем?
Вообще не призываю переписывать, просто мне странно видеть "использование mmaps ускорило наш код в 25 раз" вместо "использование mmaps позволило нам удалить кучу легаси-кода, теперь проект гораздо проще поддерживать".
Если ты не пишешь что-то что делает много мелких чтений с диска - у тебя в принципе нет необходимости это оптимизировать.
Если что-то начало делать много мелких чтений с диска и оптимизации дошли до этого чего-то - кажется логичным взять mmap и ускорить код в 25 раз, а не писать легаси код для кешей и всего связанного, чтобы потом заменять его на mmap
можно достичь той же скорости, что и с memory map
Линейное чтение больших файлов (большими кусками) - да, будет приблизительно одинаково. Если нужно возиться с одними и теми же данными в небольшой области - mmap-решение может быть проще и быстрее.
Но вообще кеширование есть в "обычных" fread/fwrite из libc, размер буфера можно потюнить, непонятно почему сравнивали только сисколы read/write с mmap().
memory maps в основном упрощают жизнь
Да, но с нюансами. read/write при ошибке чтения/записи возвращают эту ошибку, и обычно программист к этому готов. С mmap в таком же случае приложение может получить SIGBUS и упасть. Программист и пользователи обычно к этому не готовы.
Управлять памятью в случае с mmap тоже сложнее. C read/write вы выделяете буфер и с ним работаете, все более-менее предсказуемо. А если вы сделаете в виртуалке с 8Gb памяти mmap на файл 32Gb и начнете его читать в разных местах, то контролировать память становится довольно проблематично. Все будет делать ОС, и иногда довольно непредсказуемо.
Функция CreateFileMapping была в WinAPI как минимум в Windows NT 3.51, а это 1995 год. Похвально, что через 30 лет она появилась и в таком "новаторском" продукте как Go.
Так в пакете syscall этот метод тоже чуть не с рождения гошки. Да и в статье речь о том, что человек сделал обертку над сисколлами.
Системный вызов mmap как часть POSIX появился в середине 1980-х годов. Смысл вспоминать про WinAPI нет - как технология есть давно.
Но mmap не серебряная пуля - есть и недостатки. При дефиците ОЗУ от нее больше вреда, чем пользы.
Однако сейчас, когда ОЗУ относительно недорогая, такие концепции обретают новую жизнь. А многие с ними знакомы слабо .... и очень правильно просвещать, смотрите а вот есть такое и такое, подумайте и если что - используйте пожалуйста.
Как memory maps (mmap) обеспечивают в 25 раз более быстрый доступ к файлам в Go