It has to be remembered that to draw a chart, Daisy needs to build a series of large tables, so that the chart has the required interactivity.

This means that any of the following factors will seriously affect the speed of drawing of a Daisy Chart :-

• The database size (records and fields) affects the speed at which the data is read in a linear manner.

• The number of nodes in each mapping field is important, as when they get to a significant number, looking up a new node starts to take a significant amount of time.

• The more mapping fields there are, obviously as each has to be processed, the longer the calculation will take.

• The number of mapping fields is also significant in that there is a multiplicative effect as to the possible number of links.

How can these factors be minimised in the drawing of a Daisy Chart?

Experience says that Daisy running on a modern computer with a speed of over 300 MHz, is almost immune to database size, in that the effect of reading the data is much smaller than the problems with node and link table lookup.

But in certain circumstances, there may be an argument for using a pre-selection on the database.

As the number of nodes significantly affects the number of links, the first priority should always be to reduce the number of nodes created.

The choice of mapping format is crucial :-

• As was previously explained, always be careful with numeric fields. Either use Partition, Thousands or one of the other formats to reduce the nodes.  More...

• Use Phone Exchange or Phone Area to reduce the number of nodes with phone numbers.  More...

• Use Short Post Code in a similar way with UK Post Codes.  More...

• Shorten Text fields by applying a mask.  More...

Larger versions of Daisy have a special mapping format, List, for this type of problem.

This dramatically reduces the processing time, as the number of links is also severely reduced.

Remember though, that as with all programs, significant increases in speed can be obtained with faster hardware and more memory!