Best practices to optimize compiler Build All feature in Ope

Posted by Rom Elwell on 17-Jun-2014 13:26

Is there any information detailing the best practices for using the 'Build All' feature in OEA? We have 613 files currently in our workspace (320 of the files are Include files) and it is taking the compiler ~6 minutes to build the workspace when a 'Build All' command is issued. We do not have a benchmark to compare this metric to and do not know if there are is compiler optimization patterns we should be pursuing at this time.

Thanks.

OpenEdge Development - Forum

Posted by Thomas Mercer-Hursh on 17-Jun-2014 14:23

Yes. Not only is it pointlessly long, but it includes some practices which I find at least extremely strange if not more dubious. Why in the world would you have \Common\DataAccess on the propath and also have Common\DataAccess\DataSets??? (Yes, I know they did it in the OERI, but surely you know not to copy PSC code as if it were good practice. One of the rules of propaths should be equivalency, i.e., you should never be referencing two different levels along the same path. If you put the terminal directories in the code, e.g., DataSets and DataSources, presto you would eliminate 5 entries in the path. Likewise Modules\src .... is there something under that directory other that DC, GL, INV, LT, OE, and PO that you are trying to hide from Progress? If not, why not just put Modules\src on the propath and put the subdirectories in the code as packages.

I don't know whether you have OO code or not, but the whole idea of a package and USING is particularly clear there. But, it isn't just an OO idea. Back in the 60s I inherited a directory structure from Varnet which had directories like gl, ar, and ap, but it was the directory containing these which was on the propath. This meant, for example, that I could have a 4 element propath that included one directory for what the developer was currently working on, one for custom source for the customer, one for the r code and one for the standard release. Within each one would have gl, ar, ap, etc. as needed so that promoting a standard release module to customer code and then modifying it, for example, was completely straightforward. I quickly became unhappy with the very large number of files under each of these application directories and so started introducing packages within the application. I.e., ar/cust would have all the programs that dealt with editing, listing, and inquiring on customers. op/orde would have everything to do with order entry, etc. This is packages, but in strictly procedural code.

Sorry to rant and I know and appreciate that it isn't going to be an easy transition to fix, but if you would pick a small number of base directories (one?) and put everything under that with the package paths in the code, I am confident you would see much higher compile performance and possibly even runtime performance .... not to mention ease of maintenance. What happens now when you see a reference to X.p? You need to look in 30 different places to find it? Not to mention needing to keep unique names at the end of all of those paths whereas the path would be part of the uniqueness if you did as I suggested.

How do people do these things to themselves!?

All Replies

Posted by Peter Judge on 17-Jun-2014 13:40

6 minutes seems like a long time. Is some the source code on a network (UNC) path?

Also, what version is this on?

-- peter

[collapse]

From: romelwell [mailto:bounce-romelwell@community.progress.com]
Sent: Tuesday, 17 June, 2014 14:27
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] Best practices to optimize compiler Build All feature in OpenEdge Architect?

Best practices to optimize compiler Build All feature in OpenEdge Architect?

Thread created by romelwell

Thanks.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Rom Elwell on 17-Jun-2014 13:54

Peter,

We are running 10.2b (with a planned migration to 11.x this Fall). Our OEA workspace contains two projects that are using a shared AVM. All source code is local to the build machine (using SVN 'sandboxes'). The OEA workspace has two projects that build the binaries to a common directory in the workspace. The file directory for the OEA workspace looks like this:

./ ( root workspace directory)

./project1 (directory with 'common' classes and includes in subdirectories)

./project2 (directory with 'business' classes and includes in subdirectories)

./rcode (common directory where rcode files created from project1 and project2 are stored during 'Build All'/compile)

Posted by Rom Elwell on 17-Jun-2014 14:03

One more question for Peter (and other, more experienced engineers than myself),

Could our Propath definition be negatively impacting the compiler? Below is the Propath definition for the Shared AVM used in our workspace. As you can see, we have numerous subdirectories in the Propath and I'm not sure if modifying the order of the Propath entries has any impact on compiler performance.

<?xml version="1.0" encoding="UTF-8"?>

</propath>

Posted by Thomas Mercer-Hursh on 17-Jun-2014 14:23

How do people do these things to themselves!?

Posted by Roberta Miller on 17-Jun-2014 14:27

Hi Rom,

Please take a look at knowledge base article 000015757, "Bottleneck in Initialize Tooling in 10.2B OpenEdge Architect" at knowledgebase.progress.com/.../P175985. There was a defect in OpenEdge 10.2B that may apply to you if:

You are running a 10.2B service pack between 10.2B02 and 10.2B04 inclusive.
You see the message "Initializing OpenEdge tooling" in the status area during your six-minute wait.

If this is the issue, you can resolve it by applying service pack 10.2B05 or later (our latest service pack 10.2B08 would be best). The defect is also fixed in in 11.0 and higher, so it should go away when you upgrade.

HTH,

Roberta

Posted by Anil Kumar on 17-Jun-2014 14:31

Hi romelwell,

Following are some of the key options which will minimize the build process.

1. Turn on ‘Build only when source files are newer than r-code’ option in Project Properties page. This will compile only those source files for which no up-to-date .r files are present. This option can save time when compiled code already exists in the destination (rcode) directory.

2. Order of PROPATH entries in the PROPATH page and number of entries in the PROPATH page

During the active development (this is not the case of force clean or manual Build operation):

3. Turn off ‘Build Automatically’ option in Project menu

4. Uncheck ‘Compile on save if required’ option in Preferences page

Starting from 11.0 of PDS OE (aka OpenEdge Architect) there is an option to Exclude a folder/file(s) not to be part of the build. I.e., build process will not look for specific folder or files of folder during the compilation.

Hope this helps.

Thanks and Regards,

Anil Kumar.

[collapse]

From: romelwell [mailto:bounce-romelwell@community.progress.com]
Sent: Tuesday, June 17, 2014 11:57 PM
To: TU.OE.Development@community.progress.com
Subject: [Technical Users - OE Development] Best practices to optimize compiler Build All feature in OpenEdge Architect?

Best practices to optimize compiler Build All feature in OpenEdge Architect?

Thread created by romelwell

Thanks.

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Rom Elwell on 17-Jun-2014 20:23

Thomas, Thank you for your detailed reply. While I find your communication skills to be brash at best, your analysis was spot-on and I was able to refactor the workspace based on your reply. Compilation time was reduced from 6:45 to 1:30.

Posted by Thomas Mercer-Hursh on 18-Jun-2014 09:44

Sorry to seem a bit rough, but that sort of thing drives me nuts. I am surprised that you were able to refactor so quickly, but the results sure speak for themselves. I think you will find greater clarity and obviousness in working with the code going forward as well.

Posted by Rom Elwell on 18-Jun-2014 10:52

Roberta, Thank you very much for this information! We have documented this as an issue that we will address immediately upon return of key team members early next week. We appreciate your continued support!

Posted by Roberta Miller on 18-Jun-2014 11:04

Hi Rom,

I just want to note that if you completely flattened out your propath according to Dr. Mercer-Hursh's suggestion you probably won't see the symptoms of defect PSC00231814 any more, even if you were seeing them beforehand. It has only been observed when there are nested directories in the propath. It sounds like you got good improvement from modifying the propath. That could be simply because the new propath is more efficient, but it could also be that you were hitting the defect and aren't any longer.

Regards,

Roberta

Posted by Rom Elwell on 18-Jun-2014 11:15

Hi Roberta,

We still have nesting in the propath, however, the depth of nesting has been greatly reduced and isolated in one subdirectory. Thus, I feel there is still merit in reviewing the KB with my team when they are all in the office again next week.

Posted by Thomas Mercer-Hursh on 18-Jun-2014 11:15

Nothing quite like a defect that only affects bad practice! :)

This thread is closed