Pascal - Threads - Separate Delta/Tick Calculations from `TADPrecisionThread` Implementation

[LK-Daniel]

At present, all of the Delta and Tick Rate Calculations are implemented within TADPrecisionThread.

Aside from conflating the code, this also leads to the following caution from FixInsight:

[FixInsight Convention] ADAPT.Threads.pas(356): C103 Too many variables in 'TADThreadPrecision.Execute' (9 variables)

It would be a good idea to abstract these calculations from TADPrecisionThread, thus keeping it all together, and eliminating the aforementioned FixInsight caution.

[LK-Daniel]

This requires quite a bit of reworking of TADPrecisionThread, but it does make sense to define an Interface (and corresponding Implementing Class) to separate the Delta Extrapolation Process from the TADPrecisionThread class.

Currently, the plan is to define an interface named IADPerformanceLimiter, and a corresponding implementation named TADPerformanceLimiter to provide the necessary functionality, and consume this in TADPrecisionThread.

An added advantage of doing this is that we can use the same Performance Limiter functionality in other contexts, such as in a Precision Timer class (which COULD be named TADPrecisionTimer)... as an example.

[LK-Daniel]

As of now, this Issue is "Priority One".

I need to wrap this one up before it becomes more complicated with higher-level implementations.

[LK-Simon]

I'm picking this one up now... I get your points, @LK-Daniel, and agree there's merit to abstracting the performance calculation routine from TLKPrecisionThread.

[LK-Simon]

Issue #115 lays the initial groundwork for moving the calculation routines out of TADPrecisionThread but more work remains to be done before this can fully take place.

Mainly, the current TADDeltaFloat class is using a TADMap<ADFloat, ADFloat> to hold the absolute reference values. The problem there is that this Map will grow infinitely over time, and consume massive amounts of memory (not to mention reduce performance of calculation over time).

What's needed is a TADCircularMap with a fixed allocation limit (which can be set on a case-by-case basis to fit the specifics of each usage). This will bump redundant historical values out to make space for new ones, keeping the allocation of memory somewhat-static, and the performance requirement will never be greater than the maximum needed to for that static number of values.

This is the next major change needed as part of this transformation process. Pay attention to all other Issues making reference to this one.

[LK-Simon]

TADDeltaFloat is now operational, and so I can begin seriously addressing this issue now.