Hi, Eduardo -
What I'm going to suggest may or may not be feasible for your situation, but I will throw it out there for you to consider...
I think it would be useful to have some baseline data that contains some finer granularity that simply the overall completion time. Can you add timing/recording functionality to this process that collects data at several key and/or critical points? I would then compile/run with the Build 1892 runtime environment to collect this baseline dataset and verify that the overall completion time is similar to that observed before (roughly 18 minutes, I believe).
Once that data is collected, compile/run with the Build 3356 runtime environment and compare the datasets.
If you see, say, one part of the overall process that is performing abysmally but you still cannot determine possible causes, then perhaps you can include additional, finer data collection points in that portion of the process, then repeat.
This approach is how I would attack this issue if I were in your situation.
The GlobalMemoryStatus or GlobalMemoryStatusEx Windows API functions may be helpful. I can supply you with the PB structure(s) and external function declarations to interface with these API's, if desired.
Best regards, John
You only need the custom PB.ini if you want them ON. ;-)
I tested it and as indicated, it has not had any positive effect on speed