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


0

Я часто использую 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 секунд, поскольку я не могу представить, что время медленного поиска находится в допустимых пределах.


Вы жалуетесь, потому что поиск в нескольких файлах занимает 10 секунд !?
DavidPostill

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

Ответы:


1

Деннис

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

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

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.