95% of all problems would be solved by posting the project file instead of just guessing into a black box.

I installed visual studio 2019 and loaded your project and got this error

C:\Users----\Downloads\psector.ultrasimplifiedprofiling\psector.vcxproj : error  : Error HRESULT E_FAIL has been returned from a call to a COM component.

sigh... why does this stuff never work the first time.

... C++ didn't install right maybe? I have no idea why I'm a magnet for such obscure errors.

[edit] hmmm........ maybe a combination of visual studio "wanting to restart to finish" + windows feature update applying on restart clobbered a dependency. I bet that's it.

GG Microsoft.

[edit] it compiles now.

[edit] nvm it's a user pragma

Well this looks wrong. I sure as heck don't have a "23bit" or "13bit" color screen.

One thing I notice is

  al_set_target_bitmap(dest);

called for every sprite. That may incur a cost (and the driver update may have reduced that cost). If the target is always a render buffer, or the screen, etc, you should only be calling that once [per actual need] as the driver may be using the moving [current target] to decide when to cache / move memory around. (complete guess but it's definitely different than I've ever coded my projects)

profile shows

7% of time was spent just in al_set_target() on my machine
14% on al_draw_bitmap

though i'm not used to this MSVC UI for profiling

[edit]

24% was in waiting for events, so it's either vsync or set to only draw a set rate.

[edit]

I set al_set_new_display_option(ALLEGRO_VSYNC, 2, ALLEGRO_REQUIRE); //vsync off

600: Advance: 0.0ms  Render1: 7.0ms  Render2: 0.5ms  Frame: 7.4ms
600: Advance: 0.0ms  Render1: 7.5ms  Render2: 0.5ms  Frame: 8.0ms
600: Advance: 0.0ms  Render1: 7.9ms  Render2: 0.3ms  Frame: 8.3ms
600: Advance: 0.0ms  Render1: 9.9ms  Render2: 0.3ms  Frame: 10.3ms
600: Advance: 0.0ms  Render1: 7.3ms  Render2: 0.3ms  Frame: 7.6ms
600: Advance: 0.0ms  Render1: 9.5ms  Render2: 0.3ms  Frame: 9.8ms
600: Advance: 0.0ms  Render1: 7.3ms  Render2: 0.3ms  Frame: 7.7ms
600: Advance: 0.0ms  Render1: 9.5ms  Render2: 0.5ms  Frame: 10.0ms
600: Advance: 0.0ms  Render1: 7.9ms  Render2: 0.4ms  Frame: 8.2ms
600: Advance: 0.0ms  Render1: 7.7ms  Render2: 0.3ms  Frame: 8.0ms

I'm getting over 100 FPS even with al_set_target_bitmap (still uses 8% cpu time!). Granted, it's a GTX 1060.

Still, it's showing plenty of time taken in the event queue so maybe I'll need to force no vsync with my drivers. That, or you did something wrong with the event queue/timers and it's forcing it to wait.

[edit] Still blowing 25% time waiting for events with vsync forced off. Take a look through in your event handler / timing code when you can, I'm out of time for the moment.

You know, the second I look at that, it looks completely normal. I was expecting something more... squirrelly.

[edit]

Wait, no... how... if you're waiting for Allegro to fire off an event, it's literally impossible to exceed that speed. I don't think that's how you'd setup timing for a benchmark.

Here you set a timer based on the refresh rate of the screen:

//psector.cpp:232
  alTimer = al_create_timer(1.0 / update_rate);
  al_register_event_source(eventQueue, al_get_timer_event_source(alTimer));
  al_start_timer(alTimer);

and that's the only thing triggering the exit from the while loop above.

p.s. profilers rule.

The game runs at a maximum of 60fps. The timings I've been looking at are those measured by my own timing system, which measures the render1 and render2 times and outputs them once the level has been running for 10 seconds. You're right in saying that this system isn't ideal for profiling using the MSVC profiler. Commenting out "if (timer_value > 0)" and "if (timer_value == 0 || ++framesSkipped == 4)" should allow it to run flat-out.

UPDATE:
I added the optimisation to only call al_set_target_bitmap when it needs to change. I see a boost to Render1 performance but strangely, al_flip_display consistently takes longer. I have split it out from the Render2 timing, which confirms that all the Render2 time is taken up by al_flip_display.

Direct3D
Without targetBitmap optimisation
	Render1: 9.3ms  Render2: 0.0ms  Flip: 0.5ms Frame: 9.8ms
	Render1: 9.2ms  Render2: 0.0ms  Flip: 0.6ms Frame: 9.9ms
	Render1: 9.3ms  Render2: 0.0ms  Flip: 0.7ms Frame: 9.9ms
	Render1: 8.9ms  Render2: 0.0ms  Flip: 0.5ms Frame: 9.5ms
	Render1: 9.0ms  Render2: 0.0ms  Flip: 0.5ms Frame: 9.5ms

With targetBitmap optimisation
	Render1: 6.5ms  Render2: 0.0ms  Flip: 0.9ms Frame: 7.5ms
	Render1: 6.9ms  Render2: 0.0ms  Flip: 1.0ms Frame: 7.9ms
	Render1: 6.9ms  Render2: 0.0ms  Flip: 0.9ms Frame: 7.9ms
	Render1: 7.4ms  Render2: 0.0ms  Flip: 1.0ms Frame: 8.4ms
	Render1: 6.7ms  Render2: 0.0ms  Flip: 1.0ms Frame: 7.7ms

I also added an option for it to run flat out, without waiting for a timer event. When I enable that, I get these results:

With RUN_FLAT_OUT and targetBitmap optimisation
	Render1: 7.9ms  Render2: 0.0ms  Flip: 8.0ms Frame: 16.0ms
	Render1: 7.6ms  Render2: 0.0ms  Flip: 8.0ms Frame: 15.7ms
	Render1: 7.4ms  Render2: 0.0ms  Flip: 7.7ms Frame: 15.2ms
	Render1: 7.4ms  Render2: 0.0ms  Flip: 7.3ms Frame: 14.7ms
	Render1: 6.0ms  Render2: 0.0ms  Flip: 8.7ms Frame: 14.8ms

This is with vsync off using ALLEGRO_REQUIRE, although as you say the driver does not necessarily honour that.

Updated project:
https://drive.google.com/file/d/1RfEbTlI3yn2lzxaClDGe9Sb3j0ZYBPO9/view?usp=sharing

See these lines in updated project:
#define RUN_FLAT_OUT 0 (psector.cpp)
#define SET_TARGET_BITMAP_OPTIMISATION 1 (sprites.cpp)

Intel Core i5-3570K with integrated Intel HD Graphics 4000 GPU

No, it's a desktop.