58558916 improve run manager opening speed

[lefticus]

Opening Pat:

Linux RelWithDebInfo, BigPatTest (50% complete):

Before Changes: 20s
After Changes: 10s

Windows Release Build, BigPatTest (50% complete):

Before Changes: 30.1 s
After Changes: 21.9 s

[lefticus]

@elainethale I'd like you to evaluate this again. If it is still not fast enough, please quantify what you are seeing. On my system, windows (Release build) with a fully completed BigPatTest load:

Before my changes: 65s
After my changes: 29s

I'm hitting the wall to the point that I've begun parallelizing the parsing of the database data to the extent that I can.

Please compare on your system develop vs this branch so I can verify if I've managed any performance improvement on your system. To make the process less painful, I've just updated my branch to the latest develop head.

Also, I know that a lot of signals are processed. If you are using AQTime exclusively, I'd be suspicious that its signal tracking is interfering with the performance timing. For the sake of Windows testing, I've been simply using a stopwatch.

[elainethale]

@lefticus Thanks, Jason--I'm on it!

[elainethale]

I see 30% improvement when clocking PAT by hand or timing openPATProject in Ruby. (AQTime does not show the improvement.) Double-checking some unit tests. Assuming those are okay, will merge in the morning.

[lefticus]

Sounds good. I know that a fair number of signals are fired while building the job tree, but using something like valgrind those don't show up in the performance metrics at all. I bet we could get a performance increase from AQTime's perspective by disabling signals during loading, but that would be tuning just to the one tool and probably not show any real world difference.