Creating Your Performance Baseline

Estimated Lesson Length: 20–30 Minutes

Lesson Overview

Welcome to Lesson 7.

Throughout the previous lessons, we’ve learnt how Microsoft Flight Simulator uses your CPU and GPU, what causes bottlenecks, why stutters occur and how to understand FPS and frame times.

Now it’s time to prepare for the optimisation process.

Before making a single adjustment to your simulator, we need to establish something called a Performance Baseline.

Think of this as your starting point.

Without a baseline, you’ll never truly know whether your simulator has improved.

What Is A Performance Baseline?

A Performance Baseline is a record of exactly how your simulator performs before any optimisation takes place.

It captures your current setup and performance under controlled conditions.

Later in the course, after you’ve made changes to Windows, graphics settings, NVIDIA Control Panel, or in-simulator options, you’ll repeat the same test and compare the results.

This allows you to answer questions such as:

• Did my FPS improve?
• Did my frame times become more consistent?
• Did I reduce stutters?
• Did I accidentally make performance worse?

Without measurements, optimisation becomes guesswork.

Why Measuring Performance Matters

Imagine a pilot flying from London to New York.

If they never check their instruments, they have no way of knowing:

• Their speed.
• Their altitude.
• Their fuel remaining.
• Whether they’re on the correct course.

Optimising a simulator without measuring performance is exactly the same.

You need reliable information before making decisions.

Why You Should Never Change Multiple Settings At Once

One of the biggest mistakes people make is changing lots of settings in a single session.

For example:

• Lower Terrain LOD.
• Turn off Ambient Occlusion.
• Enable DLSS.
• Disable AI Traffic.
• Reduce Cloud Quality.
• Install optimisation software.

The simulator suddenly feels different.

But which change actually helped?

The truth is…

You don’t know.

Good optimisation is a controlled process.

Make one or two changes.

Test.

Measure.

Compare.

Repeat.

That’s how professionals troubleshoot performance issues.

Keeping Test Conditions Consistent

For your baseline to be meaningful, every test must be carried out under the same conditions.

If one test is performed at Heathrow with stormy weather and the next is at a rural airport in clear skies, the results can’t be compared fairly.

To make meaningful comparisons, keep the following the same:

• Airport
• Aircraft
• Weather
• Time of day (where practical)
• Graphics preset
• Resolution
• Camera view
• Test duration

Consistency is essential.

Recording Your Airport

Choose an airport that reflects the type of flying you normally do.

Busy international airports are useful because they place significant demands on your system.

Examples include:

• EGLL – London Heathrow
• KJFK – New York JFK
• KLAX – Los Angeles
• EDDF – Frankfurt

If you mainly fly from smaller airports, choose one you use frequently.

The important thing is to use the same airport every time you test.

Recording Your Aircraft

Different aircraft have different performance requirements.

A default Cessna places far less demand on your computer than a highly detailed airliner.

Choose the aircraft you fly most often.

Examples:

• PMDG 737
• Fenix A320
• iniBuilds A350
• Cessna 172
• Beechcraft Bonanza

Using the same aircraft for every benchmark ensures that changes in performance are due to optimisation, not because you’ve switched to a lighter aircraft.

Recording The Weather Preset

Weather has a surprisingly large effect on performance.

Heavy rain, thunderstorms and dense cloud increase GPU workload.

Strong winds and live weather can also introduce variability.

For benchmarking, it’s best to use a fixed weather preset, such as:

• Clear Skies
• Few Clouds
• Broken Clouds

Avoid Live Weather for baseline testing because conditions change continuously.

Recording Your Graphics Preset

Before changing any settings, write down your current graphics configuration.

Examples:

• Low
• Medium
• High
• Ultra

If you’ve customised individual settings, make a note of the important ones, such as:

• Terrain LOD
• Object LOD
• Cloud Quality
• Texture Resolution
• Shadow Quality
• Anti-Aliasing method

This gives you a clear record of your starting point.

Recording Your Resolution

Your display resolution has a major impact on GPU workload.

Record the exact resolution you’re using, for example:

• 1920 × 1080
• 2560 × 1440
• 3840 × 2160

Also note whether you’re using:

• Full Screen
• Windowed Mode
• Ultra-wide monitor

This information will help explain performance differences later in the course.

Measuring Average FPS

Average FPS is the overall performance across your test.

It gives a general indication of how smoothly the simulator is running.

However, remember what we learnt in Lesson 5.

Average FPS doesn’t tell the whole story.

Frame consistency is equally important.

Recording Lowest FPS

Your lowest FPS often occurs during the most demanding moments.

Examples include:

• Taxiing at a busy airport.
• Looking towards terminal buildings.
• Heavy cloud.
• Final approach.
• Touchdown.

Recording your lowest FPS helps identify the most stressful situations for your system.

Recording Highest FPS

Your highest FPS usually occurs when system demand is lower.

Examples include:

• High-altitude cruise.
• Looking away from busy scenery.
• Flying over water.
• Rural areas.

This gives you an idea of your system’s maximum performance under lighter workloads.

Identifying The Limiting Component

Open the Developer Mode FPS Counter.

Observe:

• MainThread
• GPU

Ask yourself:

Which component is limiting performance?

If MainThread is highlighted as the limiting factor, your CPU is currently the bottleneck.

If GPU is highlighted, your graphics card is doing as much work as it can.

This information is critical because later optimisation steps will depend on whether you’re CPU-limited or GPU-limited.

Recording Your Results

Create a simple benchmark table.