.NET OpenClient - Performance/generation optimization

Posted by danielb on 04-Aug-2017 03:12

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:

  1. The static constructor of the AppObject is 114k lines long, setting up all the stored and cached dataset and temp-table meta-data.
  2. 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.

OpenEdge General - Forum
Posted by Brian K. Maher on 04-Aug-2017 06:36

When we first wrote Open Client we did combine duplicate temp-tables and datasets down to a single instance but got massive complaints because it made things unclear and much harder to do things like append one thing to another so we changed it to what you have now.
 
Using SubAppObjects may have a beneficial effect on this.  Give them a try.
 
 

All Replies

Posted by Brian K. Maher on 04-Aug-2017 06:36

When we first wrote Open Client we did combine duplicate temp-tables and datasets down to a single instance but got massive complaints because it made things unclear and much harder to do things like append one thing to another so we changed it to what you have now.
 
Using SubAppObjects may have a beneficial effect on this.  Give them a try.
 
 

Posted by danielb on 07-Aug-2017 19:47

Thanks, Brian. We'll give multiple SubAppObjects a go.

In the meantime, we managed to call fire off the static constructor in a background thread at application startup, so while the delay is there, it is hidden from the user while they enter their password details.

This thread is closed