Performance is always a very subjective issue.

Whenever the application performance get’s an issue the first step should be to get objective figures to be able to have numbers to compare and to be able to show improvements after any form of changes.

Using Performance Test the technical infrastructure might easily be tested. In case the database might be part of the issue Database Performance might help to understand some of the database implications.

Typical issues might be

1. not enough memory. Best check for available memory. Each TradeDesign process should have abt. 200 MB memory available.
2. not enough CPU cycles available. Sometimes due to processes running in an endless loop and eating all available CPU power.
3. network timeouts when accessing other infrastructure (printer, interfaces, database, client)

If the infrastructure seems not to be the issue, then the next step is to check the application and there a typical next step is to generate a trace of an action which takes too long.

For that purpose, actions or events need to get identified which take too long. Those actions should be checked whether the reported performance issue can be reproduced at the customer production system, at the customers test system and in our customer mirror installation.

If the issue can be reproduced, another reproduction should be done with activated trace with 'debuglevel_info', where all triggered user interactions are written to the trace file. By that the response time for every user interaction is logged in the trace and no manual time registration is needed.

When the issue can be identified within the info trace and the times are showing the expected slowness, the next step is to execute the same reproduction sequence with a profiling trace.

When a profile trace is activated, the system slows down and the times registered are not the same as without trace, but those times allow to identify slower parts. When analyzing profiling traces, it should be kept in mind that the output of every line takes a certain time. The simpler the traced command, the higher the relative influence of the trace onto the execution time. E.g. the trace of “isempty” has a much bigger impact than the trace of a streamsort or a tokenize command.

To be able to exclude very simple commands from the profiling trace, there is a text file TDPRFEXC.TXT available to exclude certain rules and/or commands from a profiling trace. TDPRFEXC.TXT holds a list of rules / commands to be excluded from the trace. See TD documentation for more details.

Analyzing this trace is done with the GENPRF tool which shows per rule

1. number of executions
2. used time (accumulated time between entry and exit of the rule)
3. used net time (accumulated time minus the time spent in rules called within the rule)
4. average net time (net time divided by number of executions)
5. peak time (maximum used time, to identify single exceptional long executions)
6. peak net time (maximum net time)

When using the development platform Trade2, the integrated profiling trace visible in one of the watch panels might be used.

Typically, performance is reduced by many different and independent factors, thus there is typically no single change which solves the issue.

It is important to identify the most time-consuming parts, as optimization there will gain the biggest overall effect.

A typical approach is to sort by descending used time to identify the most time-consuming parts.

Then take a look into the sources and check the rule and it’s called sub rules.

For every long running entry, it should be checked whether there is a good reason for the used time and the number of executions.

There are many triggering reasons for slow performance.

1. An expensive rule is executed much too often. E.g. moving the invariant logic from the inner loop to a more outer place might reduce the number of calls.
2. The database access is executed too often reading the same data multiple times
3. Loops are used instead of powerful TD built in commands
4. Is the number of executions a multiple of the number of objects (e.g. accounts or conditions) used, probably too often called.

Often linear searches in growing datasets are implemented, where the execution time grows exponentially with the number of elements. Check for switching to binary searches instead.

Another issue might be to reread data again and again instead of loading the data into a module instance and use the data from there.

Or using of loops to handle data character by character, which is for sure a very poor solution.

Another issue might be wrong using of cache or the usage of a cache on the wrong level. If a complex logic is needed to determine which database entry should be read and used, a cache should be used to cache the result of the complex logic. A cache of the database access would only be of little help, as the complex logic has to be executed for every usage.

Another area might be the volume of data that needs to be transmitted between the server and the client. If many fields with long value lists are visible perhaps in a grid, the amount of data might get very big and needs a long preparation and transmission time.

More hints and details are available in the DOKA-NG developer documentation in Performance in TradeDesign Software.