Как я могу диагностировать причину значительно более медленного времени, необходимого для завершения «поиска файлов по строке» при использовании Zend Studio?

248
Dennis

Я часто использую Searchфункцию внутри Zend Studioпрограммного обеспечения (которое построено поверх Eclipse). Я использую это много. Вероятно, 10-100 раз в день.

Я испытал таинственное разнообразие во времени поиска, когда я использовал Поиск, чтобы найти строку в одном из файлов внутри Проекта. Часто это занимает всего секунду, чтобы завершить поисковый запрос. Но иногда это занимает 10-20 секунд, и это проблема, которую я пытаюсь решить / диагностировать.

Что я делаю:

  • нажмите Ctrl-H (открывает меню поиска)
  • введите строку поиска
  • нажмите Поиск
  • обычно это занимает около 1 секунды или меньше, но иногда это занимает 10-20 секунд [и это проблема]

Что я вижу

enter image description here

Это происходит спорадически, не всегда, но, тем не менее, часто.

Что я пробовал:

я пытался

  • ограничение 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 строк для медленного, примерно так:

Process Name: ZendStudio.exe Operation: ReadFile Path: jpgraph\src\jpgraph_plotband.php Result: SUCCESS Detail: Offset: 0, Length: 8,192, I/O Flags: Non-cached, Paging I/O, Priority: Normal 

Мое предположение о причине медленного поиска

Я предполагаю, что в первый раз файлы, возможно, действительно читаются, но во второй раз они где-то полностью кэшируются, и поэтому существует разница в скорости. Я полагаю, что на чтение всех файлов в первый раз уходит около 40 секунд, и всего 2 секунды, чтобы снова просмотреть их полностью, когда они кэшируются.

В этом смысле кеширование объясняет эту невероятную разницу в скорости. Однако мне стало интересно, есть ли у меня медленный, старый или сильно фрагментированный диск для поиска, занимающего 40 секунд, поскольку я не могу представить, что время медленного поиска находится в пределах приемлемой нормы.

0
Вы жалуетесь, потому что поиск в нескольких файлах занимает 10 секунд !? DavidPostill 8 лет назад 0
Да. Я ищу определенный набор файлов, который обычно занимает 1 секунду. Так что 10 секунд это очень заметно. Dennis 8 лет назад 0

1 ответ на вопрос

1
RHaguiuda

Деннис

В прошлом у меня была такая же проблема, как у вас, и я использовал Process Monitor от Sysinternals для диагностики своей проблемы. Так как это программное обеспечение показывает все, что происходит "под капотом" в Windows, возможно, оно может вам помочь.

Это довольно сложно найти решение, но это может помочь, если у вас есть терпение и правильно установить фильтры в Procmon. Вам нужно установить фильтр для вашего процесса (вашего исполняемого образа), чтобы он фиксировал только то, что делает ваше программное обеспечение.

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

Похожие вопросы