Свежие комментарии

распаковка хоффмана - это у вас ZFS наверное, там много чего может оказаться если цепочка буферов настроена неоптимально. А при работе с SSD - у него вроде большой внутренний размер страницы, кто-то говорил что 64К, и оно может плохо ложиться в маленький буфер файла. Но первичны конечно именно ваши экспериментальные замеры.

Сферически в вакууме, мапирование в виртуальной памяти - это самый естественный и дешевый доступ, поскольку достигается zero-copy и размер окрестности выбирается автоматически исходя из наличия свободной памяти, кроме того о распараллеливании чтения думает вместо нас операционная система (с тем или иным успехом;) А при чтении файла буфера копируются с места на место, проверяются постоянно границы буфера, указатель (который tell/seek) надо постоянно двигать - масса лишней работы.

В яндексе еще больше 10 лет назад индекс читался кусочками с помощью
ptr = mmap((caddr_t)NULL, size, PROT_READ, MAP_SHARED, fd, offset)
а потом сразу munmap(), поскольку целиком файл не умещался в 32bit.
При нескольких словах в запросе и множестве параллельных запросов - оно как-то все распараллеливалось внутри FreeBSD+SCSI вполне замечательно. При явном чтении получалось хуже.

Не знаю как сейчас с mmap64.

И еще :), раз уж вы читаете комментарии, значит подробности могут быть интересны.

Если код читает по байтам (для FILE это getc_unlocked), то байтовое чтение и чтение через mmap ( return buf[bufp++]) - примерно одинаково по времени (а основное время там уходит в свисток - в распаковку хаффмана, более гранулярно я уже не бенчмаркал). Т.е. fgetc/getc_unlocker действительно сильно неэффективны.

А если код читает кусками (по строкам RAW т.е. несколько килобайт) - то те самые 200-300 миллисекунд разницы на 25 мегабайтах.

Да, это SSD. На обычном (хм. обычном массиве, у меня одиночных HDD нету) тоже померяю.

UPDATE: а диск не должен никак влиять. Файл маленький, кэш большой, все тайминги - несколько запусков, но первый запуск (с поднятием в кэш) не считается.

Интересно. Значит у меня устаревшие воспоминания.
Видимо ему advise не хватает основательно. А вы проверяли на SSD или на обычном диске?

Дошли руки это место побенчмаркать.

FreeBSD, single thread, файл на 20+ мегабайт.

mmap() гораздо медленнее, чем файловый доступ. Т.е. на 20-25 мегабайтном файле - лишние миллисекунд 200-300. Это если просто MAP_PRIVATE. MADV_WILLNEED и MAP_NOCORE несколько улучшают.

сдается мне, что с точки зрения ускорения загрузки (заметного причем) достаточно поменять юзер-профиль (старый прибить), ибо биты *в основном* гниют там.
кстати - испытать это можно безопасно - просто создаешь нового юзера и грузишься в ём.

Я вот тоже темный и FILE* милее всяких цплюсплюсовых наворотов.
По-любому быстрее всего - тянуть файл в память и потом быстро-быстро препарировать.
Что касается больших многокадровых RAW, наверняка ведь кадры друг от друга независимы - закачиваем каждый по отдельности в память и препарируем.

Ну одно дело для себя любимого, а другое - как корпоративное решение.

Мы тупо используем виртуальные машины на блейде и тонкие клиенты. xfreerdp нонче очень хороша, и звуки и диски отдаёт. usb ключи раздаются через какую-то железную приблуду на все vm (тоже прелесть как хороша).

Хм. Ну я пароль не ввожу. У меня автологин настроен. Я включаю компьютер и все. Грузится быстро, система установлена в марте. Но я периодически дефрагментирую диск и подчищаю автозагрузку (всякое гавно пытается туда установить что-нибудь). Надпись welcome висит не более 10 секунд.
А вот с xp ситуация была как вы описали.

Ну в 7 диск чистится стандартно утилитой Disk CleanUp. На первой закладке чистим все, на второй точки System Restore.

Ну он думает минут по 20, и его лучше пускать с редиректом в файл

Угу.
ThinApp в этом смысле идеологически правилен: мусор локален, надоело - контейнер грохнул и все. А в настоящую файловую систему ходит только куда пустили.

Но понятные проблемы с IPC и тормозит, сука. И мелкие глюки местами.

Но направление правильное.

Похоже у инсталляторов/анинстоллеров стратегия такая - инсталлятор "мониторит" и сбрасывает в лог (типа "анинсталл.дат") всю активность по файлам и реестру.
Анинстоллер затем, базируясь на этих "трейсах", чистит систему.

но в процессе жЫзни "программа" приложение создаёт (особенно в реестре) ещё "всякий мусор". Будет ли и он почищен, зависит от... (в основном, "культуры" кодеров).

беда, одним словом.