Victor Wagner wrote: > On 2010.02.05 at 20:18:19 +0200, Serhiy Storchaka wrote: >> Торможение может быть или из-за чтения каталогов (а в таких библиотеках >> каждый текст лежит в своём отдельном каталоге), или из-за вызовов stat. С > > Там нифига не каждый текст был в отдельном каталоге. Когда я это > тестировал (а это был, все же, не lib.rus.ec, а еще aldebaran), > то там было по каталогу на автора. Это, конечно, не идеальное > логарифмическое распределение файлов (идеальное было бы на 10000 файлов > 100 каталогов по 100 файлов в каждом) но близко к тому.
Да, попутал, это на fictionbook.ru каждый fb2 был в отдельном каталоге. >> первым можно справиться, перенеся все файлы в один каталог (это частично >> устранит и вторую причину). Для второго нужно смотреть, не вызывается ли > > Зависит от файловой системы. Если в этой файловой системе каталоги не > хэшированы, то десятки тысяч файлов в каталоге как раз создадут тормоза, > а не устранят их. Это зависит не от строения файловой системы, а от уровня повыше. Если мы прочитали каталог, то уже имеем в памяти все необходимые данные, чтобы больше к каталогу не обращаться. >> stat для одного файла многократно (в врапперах для st_mode, st_mtime >> st_size???), и попытаться объединить. Ну и убедиться, что самые дешёвые и >> вероятные проверки стоят первыми и не изменившийся файл не читается (у >> Печникова он читается 2-3 раза). > > У FBReader уже тогда было го-о-ораздо лучше. Но не настолько лучше, > чтобы можно было все 150000 книг lib.rus.ec положить на fat32 32-гиговую > флэшку и засунуть в N800. Я посмотрел в код — stat похоже используется только для рекурсивного обхода (чтобы отличить регулярный файл от каталога). st_mtime вообще не увидел. Первый запуск find на коллекции Альдебарана показал миллисекунду на файл (второй — на два порядка меньше), вряд ли FBReader ему сильно проигрывает. Единственное решение тут — вообще избавиться от сканирования при старте. Запустить его в фоне. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
