Как я могу диагностировать причину значительно более медленного времени, необходимого для завершения «поиска файлов по строке» при использовании Zend Studio?
248
Dennis
Я часто использую Searchфункцию внутри Zend Studioпрограммного обеспечения (которое построено поверх Eclipse). Я использую это много. Вероятно, 10-100 раз в день.
Я испытал таинственное разнообразие во времени поиска, когда я использовал Поиск, чтобы найти строку в одном из файлов внутри Проекта. Часто это занимает всего секунду, чтобы завершить поисковый запрос. Но иногда это занимает 10-20 секунд, и это проблема, которую я пытаюсь решить / диагностировать.
Что я делаю:
нажмите Ctrl-H (открывает меню поиска)
введите строку поиска
нажмите Поиск
обычно это занимает около 1 секунды или меньше, но иногда это занимает 10-20 секунд [и это проблема]
Что я вижу
Это происходит спорадически, не всегда, но, тем не менее, часто.
Что я пробовал:
я пытался
ограничение Working Setдля определенных подпапок
Ограничено File name patternsопределенными расширениями файлов
Дефрагментировал мой диск
Антивирус не сканирует
Использование такого инструмента, как Process Monitor, не собирает много информации. то есть в прошлый раз, когда я поймал это, я думал, svchostчто делал много запросов на чтение файла, но это не говорило мне много.
Вопрос
Как я могу диагностировать причину замедления поиска?
Статистика
5461 файлов, 352 папки 139Mb общего размера файлов на диске
Обновление по использованию Process Monitor
Я запускал поиск с помощью ProcMon дважды - в первый раз это было медленно, а во второй раз - быстро. Первый поиск длился 40 секунд, он же медленный . Второй поиск длился 1,8 секунды, он же быстрый . Медленный поиск повторяется в первый раз, после того как я некоторое время не использую поиск, а затем снова запускается быстро.
Я запустил diff для событий медленного и быстрого поиска, и среди всех CreateFile, QueryDirectory, Close File, ReadFile, QueryStandardInformationFileопераций для обоих запусков разница между двумя запусками была - дополнительные 2649 строк для медленного, примерно так:
Я предполагаю, что в первый раз файлы, возможно, действительно читаются, но во второй раз они где-то полностью кэшируются, и поэтому существует разница в скорости. Я полагаю, что на чтение всех файлов в первый раз уходит около 40 секунд, и всего 2 секунды, чтобы снова просмотреть их полностью, когда они кэшируются.
В этом смысле кеширование объясняет эту невероятную разницу в скорости. Однако мне стало интересно, есть ли у меня медленный, старый или сильно фрагментированный диск для поиска, занимающего 40 секунд, поскольку я не могу представить, что время медленного поиска находится в пределах приемлемой нормы.
Вы жалуетесь, потому что поиск в нескольких файлах занимает 10 секунд !?
DavidPostill 8 лет назад
0
Да. Я ищу определенный набор файлов, который обычно занимает 1 секунду. Так что 10 секунд это очень заметно.
Dennis 8 лет назад
0
1 ответ на вопрос
1
RHaguiuda
Деннис
В прошлом у меня была такая же проблема, как у вас, и я использовал Process Monitor от Sysinternals для диагностики своей проблемы. Так как это программное обеспечение показывает все, что происходит "под капотом" в Windows, возможно, оно может вам помочь.
Это довольно сложно найти решение, но это может помочь, если у вас есть терпение и правильно установить фильтры в Procmon. Вам нужно установить фильтр для вашего процесса (вашего исполняемого образа), чтобы он фиксировал только то, что делает ваше программное обеспечение.
Анализируя доступ к диску и реестру, иногда вы можете понять, в чем проблема.