почему наутилус медленный?


19

Мне интересно, почему Наутилус очень медленно открывает каталог, содержащий много файлов. Например, в моем / usr / lib dir содержится 1900 файлов, и на показ всего уходит примерно 5 с лишним секунд. Так было с тех пор, как я установил Ubuntu несколько месяцев назад, и иногда это очень раздражает. У меня нет мощного оборудования, но я знаю, что Windows Explorer намного быстрее, чем этот.

Есть ли что-нибудь, что можно сделать, чтобы ускорить это?

Ubuntu 10.04


1
Я предполагаю, что Nautilus использует ls для создания своего списка, в то время как Explorer имеет кеш.
digitxp

Что это за система? Я думаю, что это большой фактор. Это было бы "медленно" на моем нетбуке, но не так сильно на i7 с 4 + ГБ оперативной памяти.
Крис

Ответы:


27

Отслеживание выполнения nautilusпоказывает, что медлительность обусловлена ​​сочетанием двух факторов:

  • Умно отображать полезную информацию о каждом файле. Он просматривает содержимое файлов, чтобы определить, какой значок использовать, и, возможно, показать предварительный просмотр. Это можно уменьшить, отключив предварительный просмотр в настройках.

  • Он выполняет много бесполезной работы (например, statмногократный сбор каждого файла и проверка /proc/filesystemsдаже на отсутствие каталогов). Все, что вы можете сделать, это изучить программирование, улучшить программу и отправить патч. Или, по крайней мере, отправьте авторам запрос на добавление функции (пожалуйста, сделайте это быстрее).

  • Он вызывает несколько внешних процессов для каждого каталога, я не изучал, что они делают.


Хороший ответ: D! +1 за исправление + особенность запроса квеста: D
BloodPhilia

Я программист, хотя еще не достаточно хорош, чтобы внести свой вклад. Просто из любопытства, как ты сделал след?
Кодирующий район

2
@Derek: strace -f -ttt -p1234 -o nautilus.straceгде 1234 пид наутилуса. Я не проанализировал детально трассировку, просто взглянул на вывод (много вещей, связанных с подпроцессами) и материал для каждого файла (несколько stats и a openдля некоторых файлов).
Жиль "ТАК - перестань быть злым"

1
Многие из множественных stat () поступают из библиотечных вызовов, многие из glibc.
Тим Пост

ух, это было проблемой более 6 лет! почему еще никто не вложил время в это? Для начала, предварительный просмотр и статистика должны быть сделаны ПОСЛЕ перечисления файлов. Таким образом, перечисление огромных папок будет таким же быстрым, как lsи просмотр будет возможен во время загрузки предварительного просмотра. Проводник Windows работает так, если я правильно помню. Это невероятно для такой популярной программы Ubuntu, как эта. однако, не стоит жаловаться, а вместо этого вносить свой вклад
phil294

5

На вкладке «Предварительный просмотр» в разделе «Редактировать -> Настройки» попробуйте переключить все параметры на «Никогда».

Это также очень помогло мне отключить «Вспомогательные технологии». Вы можете сделать это в «Система -> Настройки -> Вспомогательные технологии». Снимите флажок «Включить вспомогательные технологии».

Вам придется выйти и снова войти, чтобы последние изменения вступили в силу.


Это дает мне очень скромные улучшения. Удаление закладок имело гораздо большее значение.
Питер Дженкинс

5

Это напомнило мне о моем разговоре с Александром Ларссоном , ведущим разработчиком Nautilus и других проектов, включая GVFS.

Джайлс в своем ответе , в частности о том, как Наутилус просматривает содержимое файлов, затрагивает основную причину, по которой Наутилус "медленный". Однако Джайлс не объясняет, почему это медленно, что может быть очевидно для некоторых, но не для других. Вот что Алекс должен был сказать:

Скажем, вы начинаете с чистого листа, то есть вы вообще не обращались к файловой системе. Теперь скажите, что вы запустили stat («/ some / dir / file»). Сначала ядро ​​должно найти файл, который в технических терминах называется inode. Он начинается с просмотра суперблока файловой системы, в котором хранится inode корневого каталога. Затем он открывает корневой каталог, находит «some», открывает его, находит «dir» и т. Д., В конце концов, находит индекс для файла.

Затем вы должны прочитать данные inode. После первого чтения это также кешируется в оперативной памяти. Таким образом, только чтение должно произойти один раз.

Думайте о HD, как о старом проигрывателе, и, как только вы окажетесь в нужном месте с иглой, вы сможете продолжать читать материал быстро, пока он вращается. Однако, когда вам нужно переехать в другое место, называемое «поиск», вы делаете что-то совсем другое. Вам нужно физически переместить руку, затем подождать, пока блюдо начнет вращаться, пока нужное место не окажется под иглой. Этот вид физического движения по своей сути медленный, поэтому время поиска дисков довольно длинное.

Итак, когда мы ищем? Конечно, это зависит от структуры файловой системы. Файловые системы пытаются хранить файлы последовательно, чтобы повысить производительность чтения, и они также обычно пытаются хранить inode для одного каталога рядом друг с другом, но все это зависит от таких вещей, как, когда файлы записываются, фрагментация файловой системы и т. Д. Итак, в худшем В этом случае каждая статистика файла будет вызывать поиск, а затем каждое открытие файла будет вызывать повторный поиск. Так вот почему вещи занимают так много времени, когда ничего не кэшируется.

Некоторые файловые системы лучше, чем другие, дефрагментация может помочь. Вы можете делать некоторые вещи в приложениях. Например, GIO сортирует полученные inode от readdir () перед тем, как заявить о них, надеясь, что номер inode имеет какое-то отношение к порядку диска (как правило, имеет), таким образом сводя к минимуму случайный поиск назад и вперед.

Одной из важных вещей является разработка хранилища данных и приложений для минимизации поиска. Например, именно поэтому Nautilus читает / usr / bin медленно, потому что файлы там, как правило, не имеют расширения, которое нам нужно для магического сниффинга для каждого. Итак, нам нужно открыть каждый файл => один запрос на файл => slooooow. Другой пример - приложения, которые хранят информацию во множестве небольших файлов, как это обычно делал gconf, что также является плохой идеей. Во всяком случае, на практике я не думаю, что вы можете многое сделать, кроме как пытаться скрыть задержки.

Он закончил со следующей запиской:

Реальное решение всей этой дилеммы - отойти от вращающихся носителей. Я слышал, что твердотельные накопители Intel потрясающие. Линус клянется им.

:-)


3
Интересно :) Однако, если поиск является основной причиной медлительности, я все еще задаюсь вопросом, почему Windows Explorer намного быстрее, чем тогда? Конечно, не из-за оборудования.
Кодирующий район

4
Если бы мне пришлось угадывать, я бы сказал, что он не выполняет магический анализ, а просто выполняет обнаружение файлов на основе расширения (я могу подтвердить это для Windows XP).
Брюс ван дер Коой

2
Точно. Проводник (по большей части) не производит никакого анализа файлов, он просто использует расширение. Если ему нужно сделать предварительный просмотр или прочитать значок, то он должен открыть файл. Вы можете увидеть это, если откроете большую папку с файлами .exe. Расширение оболочки может заставить Проводник открыть файл, чтобы сделать также анализ. Например, некоторые утилиты архивирования проверят файлы .exe, чтобы определить, являются ли они архивами SFX. MS приложила немало усилий, чтобы ускорить работу Explorer, как с реальной, так и с очевидной скоростью.
afrazier

3

Я наконец понял, что делает наутилус таким медленным: закладки.

Чтобы исправить это, удалите все свои закладки, перезапустите, а затем добавьте обратно те, без которых вы не можете жить.

Используя strace, я понял, что nautilus указывает множество файлов для каждого представления. Даже файлы, которых не было в каталоге, я просматривал во время трассировки. Я думаю, что nautilus пытается предварительно кэшировать эти закладки.

У меня был один сетевой диск в качестве закладки ... это могло быть причиной того, что nautilus загружался несколько секунд.


1

Попробуйте использовать альтернативный файловый менеджер, такой как Thunar. Thunar намного быстрее загружает списки каталогов и более стабилен для копирования файлов с моего жесткого диска USB NTFS в ext4, хотя с большими наборами файлов, похоже, возникают проблемы, такие как Nautilus.

Вот ссылка на скрипт переключения https://help.ubuntu.com/community/DefaultFileManager


Отличный обходной путь! Мне нравятся "sudo apt-get install thunar" и "exo-предпочитаемый-приложения", а затем выберите Thunar в (Утилиты> File Manger) решение.
Дуд

1

Если у вас установлен xfce в системе Gnome и вы никогда его не используете, удалите exo-utils

Это исправило мою проблему, а также проблему с тем, что Chrome неправильно открывал файлы после их загрузки.


Не помогло мне exo-utils также требуется для многих пакетов, включая пакет xfdesktop4, поэтому удалить его довольно сложно: sudo dpkg -r --ignore-depen = xfce4-терминал, thunar-volman, squeeze, thunar, xfce4-panel, xfce4-verve -plugin, xfdesktop4 exo-utils
Питер Дженкинс

1

На вкладке «Предварительный просмотр» в разделе «Редактировать -> Настройки» попробуйте переключить все параметры на «Никогда».

Это также очень помогло мне отключить «Вспомогательные технологии». Вы можете сделать это в «Система -> Настройки -> Вспомогательные технологии». Снимите флажок «Включить вспомогательные технологии».

Вам придется выйти и снова войти, чтобы последние изменения вступили в силу.


1
Время открытия большой папки сократилось с 30 до 2 секунд. Печаль во благо.
wsmart

Мой пост был удален здесь другим пользователем. по-видимому. Хотел поблагодарить Джея за его пост, так как он очень сильно повлиял на мою медленную проблему с «Наутиусом». Будь реальным, будь трезвым.
wsmart
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.