OE projects (... are a trade-off that compromise performance

Posted by dbeavon on 19-Oct-2018 09:46

If we have a legacy OE ERP that is composed of 100,000 source files in a single project, it is not easy to work with in Eclipse.

One day before we reach 1,000,000 files we probably want to break that apart into ten or twenty individual projects that are logical units.

The only concern may be related to the impact this has on the ERP system at run-time.  In order for the system to work as it should, all the projects should be available to be used at run-time.  I'm assuming this means that the disjointed projects will need to be included in the PROPATH of the client sessions.

So my questions are whether (1) it is true that the separation of the projects will require a longer PROPATH, and (2) whether it is true that making additions to PROPATH will have a performance impact - since the AVM will now have to do more work to search for identifiers when using RUN or NEW().

It is unfortunate if the reorganization of ABL into projects would necessarily compromise performance.  Maybe I'm overlooking some obvious approach that wouldn't require any changes to the PROPATH.  Any advice would be appreciated.

All Replies

Posted by Shelley Chase on 19-Oct-2018 11:24

You can split up the projects for the source but publish the r-code to a single propath folder if that is desirable.

See

        Properties > Progress OpenEdge > Build, and make sure the Save r-code option is checked (the default setting).

                                                                 Set other values as appropriate. Note: The location that you specify for .r files

                                                                 must be included in the PROPATH you specified when you created the launch

                                                                 configuration.

For more detailed instructions, see Build properties page or Defining a launch configuration.

HTH

-Shelley

Posted by Patrick Tingen on 19-Oct-2018 13:39

Normally, splitting your source into several folders and adding them to your propath should not have that much impact. If your propath includes lots of folders from a network then that may negatively impact performance, but if adding a few entries results in slow performance then your setup is already wrong at this moment.

There are some settings that you could check to keep PDS running smoothly with larger projects. I will see if I can find it here on the forum

Posted by Patrick Tingen on 19-Oct-2018 13:46

Check this PDF for tips and here some more that go into more Eclipse detail 

Posted by dbeavon on 19-Oct-2018 19:52

Yes, we run code off of a NAS (NetApp).  I've watched the file IO from Progress when it is running a program for the first time and it seems very resource-intensive, mainly because of the various entries in the PROPATH.  Thankfully the "-q" parameter prevents the NAS from being abused too badly when the same r-code is executed over and over in a loop.

Shelly, I like your idea of gathering the r-code and deploying to a single destination.   I think we'd have to do the same for all our source code files because we still do a lot of dynamic compilation via query/results.  That dynamic compilation requires much of our source code to be deployed alongside the compiled code.

It would be nice if some PROPATH precedence hints could be incorporated into the compiled r-code for a program or class .  The hints might suggest the order to use when searching the paths at runtime for a given class.  IE. At compile-time the ABL compiler must resolve the references to other OO classes, and that information could be preserved for use by the runtime.  If the compiler found the related classes in a given PROPATH directory or pl file, then the information doesn't need to be forgotten.  It could be used by the AVM to look for the class in the most likely place, before eventually searching the entire PROPATH sequentially.

This thread is closed