Expanded vs unexpanded loops: Performance and functionality

As customers build larger and longer term projects with UNICOM Intelligence they begin to reach performance limits with respect to large numbers of variables. Customers are interested in using unexpanded loops and sparse data sets to avoid these performance issues. This section describes tests used to investigate performance and functionality of unexpanded loops and compare them with expanded loops.

This section lists the conclusions of the tests. For details of each test and the investigation behind the conclusions please see the following sections.

▪Unexpanded loops use less memory and CPU than expanded loops. The difference in depth of the loop is insignificant to resource usage.

Memory increases linearly with number of simultaneous interviews. This is true for both unexpanded and expanded loops but the trend is much steeper for expanded loops.

CPU increases close to linearly with number of simultaneous interviews. Again the trend is much steeper for expanded loops. CPU usage is not as significant as memory usage. However large expanded loops at reasonable load can cause large swings in CPU that might be difficult to manage.

▪Time to start the interview and page to page time differences between expanded and unexpanded loops are less significant than resource usage. All tests meet or barely exceed the goals.

▪Memory and CPU usage increases linearly with the number of variable instances for expanded loops.

▪Tests suggest that the current guideline of max 20,000 variable instances is reasonable. Response times exceed the goal and the resource usage can become unacceptably high somewhere between this level and 120,000 variable instances.

If your project requires more than 20,000 variables, consider using unexpanded loops. Exporting unexpanded loops to a flat dataset can require some extra work but it is likely that these projects require an understanding of how to analyze loops with sparsely populated data anyhow.

▪The memory used to initialize and displaying varying numbers of iterations is not significantly different up to about 400 iterations. Setting styles also has an insignificant impact on memory and CPU usage for similar numbers of iterations. With higher numbers of iterations, the memory usage becomes significant, especially since it is multiplied by the number of respondents.

▪On-path survey iteration responses are stored in the database

▪Unless the ‘Keep Off-path’ data mode is used, off-path survey iteration responses are stored in the database until the survey has completed. When the survey completes, the system attempts to remove off-path data. This succeeds if the survey was completed in one go, or if all restarts were from the cache. If a survey is restarted using sample management, off-path data not included in the replay is not automatically removed; questions that are not asked in the replay are still considered on-path.