почему наутилус является медленным?
Я задаюсь вопросом, почему Наутилус является очень медленным при открытии каталога, содержащего много файлов. Мой/usr/lib dir, например, имеет 1 900 файлов, и он берет приблизительно 5 + секунды для показа всего. Это было похоже на это, так как я установил Ubuntu несколько месяцев назад, и это иногда является действительно довольно раздражающим. У меня нет мощных аппаратных средств, но я знаю, что Windows Explorer настолько быстрее, чем это.
Есть ли что-нибудь, что может быть сделано для ускорения его?
Ubuntu 10.04
4 ответа
Трассировка выполнения nautilus шоу, что замедление происходит из-за комбинации двух факторов:
Это умно об отображении полезной информации о каждом файле. Это смотрит в содержании файлов для определения что значок использовать, и возможно показать предварительный просмотр. Это может быть снижено путем выключения предварительных просмотров в предпочтениях.
Это делает большую бесполезную работу (такой как
statлуг каждый файл многократно и проверка/proc/filesystemsдаже для некаталогов). Все, что можно сделать, изучают программирование, улучшают программу и отправляют патч. Или, по крайней мере, отправьте авторам запрос новых функций (сделайте его быстрее).Это называет несколько внешних процессов для каждого каталога, я не исследовал то, что они делают.
На вкладке "Preview" при "Редактировании-> Предпочтения", пытаются переключить все опции на "Никогда".
Это также помогло мне чрезвычайно выключить "Assistive Technologies". Можно сделать это в "Системе-> Предпочтения-> Assistive Technologies". Снимите флажок, "Включают вспомогательные технологии".
Необходимо будет выйти из системы и въехать задним ходом для последнего изменения для вступления в силу.
Это напомнило мне о разговоре, что я имел с Alexander Larsson, ведущим разработчиком для Nautilus и других проектов включая GVFS.
Giles, которого его ответ, конкретно бит о Наутилусе, смотрящем в содержании файлов, касается основной причины, почему Наутилус является "медленным". Однако Giles не объясняет, почему это медленно, который мог бы быть очевиден для некоторых, но не другим. Вот то, что должен был сказать Alex:
Скажите, что Вы запускаете с пустого большого списка, т.е. Вы не получили доступ к файловой системе вообще. Теперь скажите выполнение статистики (“/some/dir/file”). Сначала ядро должно найти файл, который в технических терминах называют inode. Это запускается путем взгляда в суперблоке файловой системы, который хранит inode корневого каталога. Затем это открывает корневой каталог, находит “некоторых”, открывает это, находит “dir”, и т.д. в конечном счете находя inode для файла.
Затем необходимо на самом деле считать inode данные. После того, как сначала считано это также кэшируется в RAM. Так, только для чтения должно произойти однажды.
Думайте о HD как старый проигрыватель, после того как Вы находитесь в правильном месте с иглой, можно продолжать читать материал быстро, как это вращается. Однако, после того как необходимо переместиться в другое место, названное “поиском”, Вы делаете что-то совсем другое. Необходимо физически переместить руку, затем ожидать диска для вращения, пока правильное место не находится под иглой. Этот вид физического движения является по сути медленным, так ищите, времена для дисков довольно долги.
Так, когда мы ищем? Это зависит от расположения файловой системы, конечно. Файловые системы пытаются хранить файлы последовательно для увеличения производительности чтения, и они обычно также пытаются сохранить inodes для единственного каталога друг около друга, но все это зависит от вещей как то, когда файлы записаны, фрагментация файловой системы, и т.д. Так, в худшем случае каждая статистика файла вызовет искание, и затем каждый открывается файла, вызовет секунду, ищут. Так, вот почему вещи занимают такое долгое время, когда ничто не кэшируется.
Некоторые файловые системы лучше, чем другие, дефрагментация могла бы помочь. Можно сделать некоторые вещи в приложениях. Например, GIO сортирует полученный inodes от readdir () прежде, чем указать им надеющийся, что inode число имеет своего рода отношение к дисковому порядку (это обычно имеет), таким образом уменьшение случайного ищет назад и вперед.
Одна важная вещь состоит в том, чтобы разработать Ваше хранение данных и приложения для уменьшения поиска. Например, это - то, почему Наутилус, читая/usr/bin является медленным, потому что файлы там обычно не имеют никакого расширения, мы должны сделать волшебный сниффинг для каждого. Так, мы должны открыть каждый файл =>, каждый ищет на файл => slooooow. Другим примером являются приложения, которые хранят информацию в большом количестве маленьких файлов, как gconf, используемый, чтобы сделать, также плохая идея. Так или иначе на практике я не думаю, что существует очень, можно сделать кроме попытки скрыть задержки.
Он закончил следующим примечанием:
Реальная фиксация для этой целой дилеммы должна переехать от вращающихся медиа. Я слышу, что Intel SSDs является потрясающим. Linus клянется ими.
:-)
Попытайтесь использовать альтернативный файловый менеджер, такой как Thunar. Thunar намного быстрее в загружающихся списках каталогов и более стабилен для копирования файлов от моего жесткого диска usb NTFS до ext4, хотя с большими наборами файлов это, кажется, испытывает затруднения как Наутилус.
Вот ссылка для сценария переключателя https://help.ubuntu.com/community/DefaultFileManager