How can I diagnose the cause of drastically slower time it takes to complete a "search files for a string" when using Zend Studio?

Question

I frequently use Search function inside Zend Studio software (which is built on top of Eclipse). I use it a lot. Probably 10-100 times a day.

I have experienced a mysterious variety in search time, when I use Search to find a string in one of the files inside the Project. Often it takes just a second to complete the search request. But sometimes it takes 10-20 seconds, and that is the issue I seek to resolve/diagnose.

What I do:

• press Ctrl-H (opens up the search menu)
• type my search string
• press Search
• usually it takes about 1 second or less, but sometimes it takes 10-20 seconds [and that is the issue]

What I See

It happens sporadically, not all the time, but it happens frequently nonetheless.

What I've tried:

I have tried

• restricting Working Set to specific subfolders
• Restricted File name patterns to specific file extensions
• Defragged my drive
• Antivirus does not appear to be scanning
• Using a tool such as Process Monitor does not gather much info. i.e. last time I caught it I think svchost appeared to be making lots of file read requests, but that didn't tell me much.

Question

How can I diagnose a cause of the search slow-downs?

Stats

5461 Files, 352 Folders 139Mb total size of files on disk

Update on Using Process Monitor

I ran my search with ProcMon on twice - first time it was slow and second time it was fast. First search ran 40 seconds, aka slow. Second search ran 1.8 seconds, aka fast. Slow search repeats first time, after me not using search for a while, and then it runs fast again.

I ran a diff for both slow and fast search events, and among all the CreateFile, QueryDirectory, Close File, ReadFile, QueryStandardInformationFile Operations for both runs, the difference between two runs was - extra 2,649 lines for slow, similar to so:

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

My guess at the reason for slow search

My guess is that first time the files are perhaps actually read, but the second time they are fully cached somewhere, and that is why there is a speed difference. I guess it does take about 40 seconds to read all the files the first time, and only 2 seconds to go through them fully again, when they are cached.

In that sense, caching explains this incredibly dramatic speed difference. I got to wonder however, if I have a slow, old, or badly fragmented drive for search to take 40 seconds, as I can't fanthom that the slow search timing it is within acceptable norm.

Answer 1

Dennis

In the past I had a problem like yours and I used Process Monitor from Sysinternals to diagnose my problem. Since this software shows everything that happens "under the hood" on Windows, maybe it can help you.

It's kinda hard to find the solution this way but it can help if you have patience and set filters in Procmon correctly. You need to set a filter for your process (your executable image), so it captures only what your software is doing.

By analysing the disk and registry access sometimes you can have some clues about what is the problem.