FWD » Core Development » Base Language

There are resources like StaticTempTable where the state is kept as BDT, and converted APIs are being called to read this state, instead of accessing the state directly. BDT instances are heavy, and FWD runtime should use as few as possible, to reduce both BDT allocation count and CPU time.

• analyze BDT usage in FWD - class members being kept for runtime purposes only need to be changed to their Java equivalent. Any complex scenarios, like maybe datetime/tz, need to be discussed.
• converted API calls where for example a character attribute is being read by FWD runtime, just to get its Java value - the Java value needs to be read directly.
• do not pass handle instances around the FWD runtime - pass the WrappedResource directly. ExternalProgramWrapper instances will be covered in #6817

Some fixes will be in 6129a/3821c.

The WrappedResource refactor will be done in #6827.

Some changes are in 3821c/14272. Ovidiu, please review.

Another idea is to replace new unknown (conversion and runtime) with a singleton instance.

Constantin Asofiei wrote:

Some changes are in 3821c/14272. Ovidiu, please review.

• the replacement of BDT (for getUniqueID and ADM-DATA attribute) is definitively a good thing: not only they take up less space but the operations are faster. I found no issues with the new code.
• some time ago, I also wrote some code for nano-timing pieces of code related to (new) persistence. I did not commit them (or rolled them back) because I was afraid of a possible performance penalty which come with the wrapping the productive code as lambdas. There is also extra code for handling non-final variables constraint of Java. I wonder whether we can find a solution to allow direct call to Impl methods in normal code, and activate the JMX wrappers only when doing profiling. Maybe as an aspect post-processing?
• replacing tableHandle().unwrapTempTable() with getParentTable() is very nice. Maybe we do something similar for default buffer? I wonder whether we can cache the result, though.

• private String getPath(int max): it does not look like an optimization to me. All characters are twice reverse d. If the original problem was the ArrayList iterator, then it cam be replaced with a (reversed) for and each element from list can be accessed directly using get(index) (it returns elementData[index]);
• private void putAnnotationImpl(String key, Object annotation): doesn't RulesTracing expect a lowercase key ?

Ovidiu Maxiniuc wrote:

AnnotatedAst:

• private String getPath(int max): it does not look like an optimization to me. All characters are twice reverse d. If the original problem was the ArrayList iterator, then it cam be replaced with a (reversed) for and each element from list can be accessed directly using get(index) (it returns elementData[index]);

The changes want to reduce the number of object allocations - String instances in this case. I've tested with and without, and the change is marginally better than the previous one. I'll continue keeping an eye on this.

• private void putAnnotationImpl(String key, Object annotation): doesn't RulesTracing expect a lowercase key ?

Fixed in 3821c/14281

• Performance improvements - avoid the ProcedureData lookup, by keeping a parallel stack of this data for THIS-PROCEDURE

Stanislav, did you start work on this?

No.

6129b/14366 contains a set of changes related to this, mainly from what profiling a large customer app showed.

7826a/14811 fixes other cases to reduce BDT usage from within FWD runtime.

There are many cases where a BDT is used as a short-lived constant value. The most of case are logical and interger s.
Can we implement a cache, similar to Integer? They have a small cache of the most used values (up to 256 IIRC) and return these instead of creating these short-lived constant values. The unknown values is just an example of such a constant. We must ensure they are immutable, or better said, use them only when they are immediately discarded (no assign or other mutation allowed).