RadarCube Desktop OLAP for Windows Forms benchmarks

The research of the RadarCube for Windows Forms library performance has been made by using the special application for performance testing.

The performance has been tested depending on 4 factors: amount of records in the fact table, amount of dimensions, length of dimensions, and amount of summaries.

There were used three common operations to calculate their cumulative time: drilling down, rotating the cube, and filtering. These operations were taken advisedly, because operations of rotating and filtering are most expensive.

The data for a cube is created by using a random generator and fetched in the TOLAPCube object by using a component implementing the IDbReader interface. Thus, the data gets into a cube without intermediate filling in tables of a DataSet object which significantly increases the cube performance, especially on large datasets.

All results include time and capacity of spent memory required for drawing the resulted grid after every operation. The testing was performed on a computer Athlon 3000XP with 1024MB of RAM.

You can download source codes of the test application from here and its compiled version - here.

Below are the results of testing:

1. Depending on the amount of records in the fact table

Following values were used on this test:

• Amount of dimensions: 8
• Amount of measures: 1
• Amount of members in every dimension: 25
• Amount of records in the fact table was being changed from 62,500 to 2,000,000 of records.

The diagrams below show the result:

Conclusions: the points on every axis are set in logarithmic scale, so there is an exact linear dependence between amount of the fact table records, and the time required to perform three common operations. The cumulative time of the most expensive operations is no more than 13 seconds even on 2 millions of records, this means that every operation takes less then 7 seconds. If we take into consideration the fact that the operations requiring the maximum time are quite rare then it is obvious that the cube shows not bad performance with quite big data size.

Conclusions: the points on every axis are set in logarithmic scale, so there is an exact linear dependence between amount of the fact table records and memory capacity required to perform three common operations. For better productivity, try to achieve that all necessary data capacity can be placed in a physical memory.

2. Depending on the amount of dimensions

Following fixes values were used on this test:

• Amount of records in the fact table: 250,000
• Amount of measures: 1
• Amount of members in every dimension: 25
• Amount of dimensions was being changed from 4 to 36.

The diagrams below show the results:

Conclusions: the performance of the cube is weakly dependent on the amount of dimensions. However increasing the amount of dimensions makes influence on the reading of the fact table and aloes increases the memory required for the cube. So, in spite of the actual independent from this factor it is recommended, however, to make as many dimensions as you really need.

3. Depending on the length of dimensions

Following fixes values were used on this test:

• Amount of records in the fact table: 250,000
• Amount of measures: 1
• Amount of dimensions: 8
• The length of all dimensions was being changed from 5 to 1215.

The diagrams below show the results (the "X" axis has a logarithmic scale):

Conclusions: here we see almost a linear dependence between the quantity of members in dimensions and the RadarCube speed. However, to increase the speed we recommend using hierarchy dimensions instead of one "flat" dimension (making multilevel or parent-child hierarchies is a good practice to increase the performance).

Conclusions: here we see a linear dependence between the length of a dimension and required memory capacity. Increase of dimension length doesn't have strong influence on memory capacity.

4. Depending on the amount of measures

Following fixes values were used on this test:

• Amount of records in the fact table: 250,000
• Amount of members in every dimension: 25
• Amount of dimensions: 8
• The amount of measures was being changed from 1 to 6.

The diagrams below show the results:

Conclusions: there is an exact linear dependence between amount of measures and performance and memory requirements. So it's recommended to minimize the amount of used measures. For example, it is possible to add rarely used measures only on a separate request of a user.