>> Hello. Thank you-all for watching.
My name is Christian Gunderman and I'm
a Senior Software Engineer on
the Visual Studio Editor Team at Microsoft.
Today, I'm going to be presenting on
Indexed Find in Files in VS 2022.
First off, what is Find in Files.
Find in Files or Control Shift F as you may know
it is a UI in VS for exhaustive full text search.
Using this tool window,
you can search various scopes such as your current solution,
current workspace, current project,
or even arbitrary folders on disk or network share.
As opposed to its much simpler cousin,
the Find in Files tool window
enables you to do a number of advanced scenarios,
such as filtering down files by pattern,
by file extension,
incrementally adding items to the results list to look at later,
doing secondary searches on top of an existing result set,
grouping, sorting,
or even doing secondary filters.
Find in Files is
a long standing essential feature of Visual Studio.
It goes back to its earliest releases.
In 2019, the UI in search procedure were rewritten from
the original C++ code to C-Sharp and WPF.
We took this opportunity to bring a number of improvements,
including improvements to accessibility,
making it easier to use,
making the UI much much nicer to look at,
and of course, improving the overall search algorithm.
The last couple of point releases,
my teammate and I have been working on
ongoing efforts to improve Find performance and scalability.
Indexed Search represents the culmination of
our efforts and provides the fastest VS Find experience yet.
This brings me to our demo.
Here I have two side by side builds of Visual Studio.
On the left, we have VS 17.1
public release with the Chromium repository open.
Let's just do a quick search.
This is going to take quite a while,
searching through 381,000 files.
While we're waiting, we could go and get some coffee.
I could go pet my dog,
maybe take a quick walk around the neighborhood, see what's up.
By the time I come back,
search is still going on.
Now, if I run Indexed Search,
it's done almost immediately and I have saved
so much time and don't have to
deal with the laps and focus that comes from waiting
for VS as opposed to VS just being ready.
As you can see,
Indexed Find can make you dramatically more productive.
Most importantly here, we were able to search
381,000 files in just a little bit over a second.
You've seen the flashy demo,
but how has VS 2022 actually improved in numeric terms?
Looking at the 95th percentile search,
when we started our journey Find took about 21.65 seconds.
Over the last couple of releases we've managed to shave
that in half and shave that in half again.
Finally, with 17.1 preview and indexing enabled,
indexing is made Find just about
instantaneous at just over a seconds.
Now you may be wondering what if I'm not a 95th percentile user?
Is my usage really indicative of 95th percentile user?
Happy to say that the typical Find scenario
should be two times as fast as before,
so you don't necessarily have to be
an enterprise user to experience benefit from
this particular feature and if you are
an enterprise scale user using an enterprise scale repository,
I'm happy to say that my SQL Server,
Chromium and other similarly sized solutions are
expected to have up to a 5X cumulative improvement.
Now 5X does not sound that large.
This includes the first search,
during which we have to discover
all the files to search and do a number
of other startup tasks that we
don't have to do on subsequent searches.
Excluding the first search,
the overall cumulative improvement can be up to
10X depending on the particular scenario,
the hardware, and the size of the solution.
How does Indexed Search work?
When you open Visual Studio and you
launch a solution or you launch a workspace,
you open a folder for the first time,
VS goes through the process of
processing that solution or workspace,
enumerating all the files.
As files are discovered,
those file names are batched up and sent to an indexer process.
Now note indexing is happening in a separate process.
Both Visual Studio and many of
its worker processes are managed code,
meaning they have a garbage collector,
meaning they have a shared thread pool and so by
putting all of this in a separate process,
we allow the indexer process to
do the heavy work of scraping file contents
and writing indexed files to disk with
minimal impact on Visual Studio responsiveness.
VS is a foreground process,
so it is given priority and then it is allowed to take
the resources it needs without
competing too much with the indexer,
which would have otherwise been in the same process.
Now when the user performs the search,
Visual Studio sends a search request to the indexer processes.
That indexer process uses the indexed files to fetch
matching names and then those names are transmitted
back to VS and VS does a brute force search on those.
This particular approach allows us to quickly
and efficiently index large amounts of content,
potentially hundreds or thousands of megabytes worth of
content without using too much additional disk space, CPU, etc.
This set of trade-offs allows us to make
a significant improvement in performance,
eliminate up to 99 percent of the files from the search,
all with minimal impact
to the scenarios that the customer cares about.
If you want to try it, all you have to do is update
Visual Studio to the latest public release,
click "Tools", "Options" to open the Options dialog.
Navigate to environment preview features and ensure
that enable indexing is checked.
Thank you for watching. I hope that you
enjoyed watching as much as I enjoyed helping build this.