Microsoft is ever striving to make its products run better. They can add yet another accomplishment to their list as Microsoft’s cloud service search engine, Bing is now running fully on .NET Core 2.1, as announced by the .NET engineering team in their blog yesterday.

.NET Core is the slimmed down and cross-platform version of Microsoft’s .NET managed common language runtime. Since Bing runs on thousands of servers spanning many data centers across the globe, .NET Core will serve as the perfect platform for it to function on.

Why did Bing migrate to .NET Core 2.1?

Bing has always run on the .NET Framework, but has been able to move to .NET Core 2.1 after some recent API additions.

Let’s take a look at the main reasons for Bing.com’s migration to .NET Core.

1. Performance i.e. serving latency

.NET Core 2.1 has led to an improvement in performance in virtually all areas of the runtime and libraries. The internal server latency over the last few months shows a striking 34% improvement. Check out the graph for a clear picture!

Souce: blog.msdn.microsoft.com

The following changes in .NET Core 2.1 are the reasons why the workload and performance has greatly improved-

#1 Vectorization of string.Equals & string.IndexOf/LastIndexOf

HTML rendering and manipulation are string-heavy workloads. Vectorization of String comparisons and indexing operations (major components of string slicing) is the biggest contributor to the performance improvement. You can find more information on this on the github page for  Vectorization of string.Equals and string.IndexOf/LastIndexOf

#2 Devirtualization Support for EqualityComparer<T>.Default

One of .NET core’s major software components is a heavy user of Dictionary<int/long, V>, which indirectly benefits from the intrinsic recognition work that was done in the JIT to make Dictionary<K, V> amenable to that optimization.  Head over to the github page for more clarity on why this feature empowers .NET Core 2.1

#3 Software Write Watch for Concurrent GC

This led to a reduction in CPU usage. The implementation relies on a JIT Write Barrier, which instinctively increases the cost of a reference store, but that cost is amortized and not noticed in the workload.

#4 Methods with calli are now inline-able

ldftn + calli  are used in lieu of delegates (which incur an object allocation) in performance-critical pieces of code where there is a need to call a managed method indirectly. This change allowed method bodies with a calli instruction to be eligible for inlining. The github page provides more insight on this subject.

#5 Improve performance of string.IndexOfAny for 2 & 3 char searches

A common operation in a front-end stack is search for ‘:’, ‘/’, ‘/’ in a string to delimit portions of a URL. Check out this special-casing improvement that was beneficial throughout the codebase on the github page.

2. Runtime Agility

The ability to have an xcopy version of the runtime inside their application denotes that they can adopt newer versions of the runtime at a much faster pace. The Continuous integration (CI) pipeline is run with .NET Core’s daily CI and it builds testing functionality and performance all the way through the release.

3. ReadyToRun Images

Managed applications usually can have poor startup performance as methods first have to be JIT compiled to machine code. .NET Framework has a precompilation technology, NGEN. On .NET Core, the crossgen tool allows the code to be precompiled as a pre-deployment step, such as in the build lab, and the images deployed to production are Ready To Run! This feature was not supported on the previous  .NET implementation.

The .NET Core team is striving to provide Bing.com users fast results. The latest software and technologies used by their developers will ensure that .NET Core will not fail Bing.com!

Read the detailed overview of the article on Microsoft’s blog.

Read Next

Say hello to FASTER: new key-value store for large state management by Microsoft

Microsoft Azure’s new governance DApp: An enterprise blockchain without mining

.NET Core completes move to the new compiler – RyuJIT