D
danielb
Guest
We use the .NET OpenClient (11.6.3) to generate the strongly typed assembly information for our proxy procedures. There are approximately 1200 individual .p procedures that we expose to our application, with approx 544 different datasets. The .dll is approximately 23MB at the moment. All of our procedures are in one of two formats: FooFetch.p: INPUT-OUTPUT dsGateway, OUTPUT dsFoo Or FooSave.p: INPUT-OUTPUT dsGateway, INPUT-OUTPUT dsFoo (this dsGateway dataset is the same definition across every proxy procedure). We have recently upgraded to Visual Studio 2015/2017, and have noticed that when debugging our application, almost 2GB is allocated onto the heap (according to Visual Studio) when our AppObject is created, and then discarded via garbage collection. A decompile of the generated .dll reveals the following: The static constructor of the AppObject is 114k lines long, setting up all the stored and cached dataset and temp-table meta-data. Each individual proxy procedure gets its own distinct definition of the datasets, even if they are the same. This is exacerbated when every procedure has a dsGateway dataset with 5 temp-tables. All up, this takes approx 7s to load all this information. Our AppObject assembly is only going to get bigger, and therefore take longer and longer. Short of rearchitecting our AppObject definitions to be extremely granular, so there are only a few datasets/procedures in each, are there any options we specify (either at generation time or runtime, even undocumented) that can improve the performance here? The options in the ProxyGen UI are limited. If not, we'll look at hiding the performance from the user. I know that Progress is guiding new development towards REST based APIs/procedures, and away from OpenClient.
Continue reading...
Continue reading...