It just occurred to me that I may have done things a bit backwards in Version 3.3. In 3.2 at startup, AIFP simply loaded a consolidated airport text, file that had been prepared some time earlier and generated the necessary indices. In 3.3, the consolidated airport file and associated indices are created at every start-up and saved only for manual reference/general interest. In either case, should conditions change, the file was/is regenerated.
As I indicated earlier, I have now assessed the effects of not including the PV5 airports for users who had no need for them. Doing so would have only a marginal impact (<10-%) in reducing airport data file size. I can only guess as to what the reduction in startup time might be, but I suspect any reduction would be of a similar order, certainly not more than about 15%. So, that approach isn't going to yield the magnitude of improvement we seek.
But, while doing this, I realized there was no need to regenerate the airport file at every startup since, once it exists, it is regenerated and saved whenever a change is made that affects it. So, in the upcoming release of AIFP, I will revert to the 3.2 approach. That should significantly reduce startup time. The downside is that, should conditions change such that the file needs to be regenerated, the first such regeneration in any AIFP session will take longer. But this should be a relatively infrequent occurrence.
Stay tuned.