I received the following response from UK Support:
I would suggest as a first step, you look at the number of fields being included in the application and validate that they are all required. Fields loaded but not referenced in any sheet objects will still use memory. I would then suggest looking at the data structure as there are quite a few tables which could require QV to link across each of these tables to locate all the items in your display table. I think it is the structure of the data model rather than the volume of records which is causing your problem."
The information sent to me below provides some useful techniques for improving application performance.
Hope this helps you as it helped me
Author: ABY, QlikTech UK.
Performance Checklist…5 quick wins…
A QlikView application can be constructed in different ways and still present the user with the same results.
However, there are a few pointers below to aid in speeding up your analysis……
1 - Memory Intensive Expressions
Wherever you see the ellipsis within QlikView you can ad a dynamic/database object/function. This does also mean that you can add complex formulas and functions to most parts of your application, including Titles, text objects, chart headers etc etc. You must remember that any object or item that requires a calculation, takes up some memory.
2 - Pivot vs Straight Table
Pivot tables give the user a massive amount of flexibility but basic straight tables are less memory intensive in large data volume implementations.
3 - Many leaf data structures
If, within your data model, you have a large amount of tables that simple contain 2 columns (usually used for codes and descriptions), you could look to using the Mapping Load and Applymap functions to pull the leaf tables closer to the fact table therefore reducing the model complexity.
4 - Remove unused data from the model
Removing data that is not required from your data model can reduce the volume and uniqueness of the data model. This reduced uniqueness and smaller model will mean the application has a reduced footprint in memory and result in faster analysis. You can simply comment the columns out to ensure that if they are needed at a later date you can easily readd them.
5 - Script side IF Statements
In most applications it is absolutely fine to add IF statements and other formulas to your charts, but in larger data volume apps or in areas where memory power is restricted you may be able to add the data to the script…for example, in a chart you may wish to just view sales for Product ABC so the expression will be something like…..
SUM(IF Product = 'ABC',Sales,0)
You could move this line to the script and create an ABC Sales column….
IF(Product = 'ABC',Sales,0) as ABC_Sales
The chart can then simply use
as the expression.
It's hard to say what the issue is right off the bat like this. The actual file size usually has little to do with the amount of RAM consumed when calculating objects. I would suggest sending this document to support.
However, here's a few things that are usually present in objects where Out of object memory occurs.
Several dimensions & Expressions, Calculated dimensions, "Expensive" expressions (Count distinct, string comparison, nested conditions based on calculations), Pivoted pivot tables, Something strange with the data structure. Unfortunately it's very hard to say what might be causing the issue in this case but I've yet to seen a document where changing the internal memory settings would be required for an object to calculate.
Out of Object Memory
This error message can occur for several reasons. Is this happening during a script reload or when a chart or object on the page is trying to reload? If it's a chart it is because of your expressions. You either have to much data, to long, or a really bad if statement in one of your expressions. Check that out, and let me know. If it's a chart please post your expressions so I can have a look at it.