Qlik Sense Performance Tuning

Reading the Reload Log

Every reload in Qlik Sense generates a detailed log. Knowing how to read it is the first diagnostic step. Go to Management Console > Apps > [App] > Reload History, or in Qlik Cloud, check the App Activity log.

// Patterns to look for in the reload log
-- SYNTHETIC KEY WARNING --
A synthetic key was generated for table [Orders]:
Fields: CustomerID, ProductID
This creates a hidden composite key table that expands in memory.
Action required: rename or alias the duplicated fields.

-- SLOW TABLE --
Loading table [FactSales]: 12,450,000 rows in 04:32
Previous run: 12,448,000 rows in 04:31 (full reload - no delta)
Action: implement incremental load to avoid reprocessing 12M rows.

-- LARGE FIELD --
Field [LegacyXMLPayload]: 48 MB, 0 distinct values used in any chart
Action: DROP this field - it's consuming RAM with zero analytical value.

Structured Diagnosis Workflow

The logic is simple: on first run, load everything and store to QVD. On subsequent runs, load only what's new or changed (delta), merge with what's already in the QVD, then store the updated QVD back.

// Complete incremental load pattern - production-ready
// Step 1: get timestamp of last load stored in the QVD
LET vLastLoad = Peek('UpdatedAt', -1, 'MaxDate');

IF IsNull(vLastLoad) OR NOT QvdNoOfRecords('lib://QVDs/sales.qvd') > 0 THEN
  // ---- FULL LOAD (first run or corrupted QVD) ----
  TRACE === FULL LOAD: loading all sales ===;

  Sales_Full:
  LOAD
    SaleID,
    CustomerID,
    ProductID,
    Amount,
    SaleDate,
    UpdatedAt
  FROM [lib://Sources/sales.csv]
  WHERE UpdatedAt >= '1900-01-01';  // load everything

  STORE Sales_Full INTO [lib://QVDs/sales.qvd] (qvd);
  DROP TABLE Sales_Full;

ELSE
  // ---- INCREMENTAL LOAD (delta only) ----
  TRACE === INCREMENTAL: loading delta since $(vLastLoad) ===;

  // Load only new/changed records from source
  Sales_Delta:
  LOAD
    SaleID,
    CustomerID,
    ProductID,
    Amount,
    SaleDate,
    UpdatedAt
  FROM [lib://Sources/sales.csv]
  WHERE UpdatedAt >= '$(vLastLoad)';

  // Load existing QVD excluding records already in delta
  Sales_Existing:
  LOAD
    SaleID,
    CustomerID,
    ProductID,
    Amount,
    SaleDate,
    UpdatedAt
  FROM [lib://QVDs/sales.qvd] (qvd)
  WHERE NOT EXISTS(SaleID);

  // Merge: existing + delta = complete updated table
  CONCATENATE(Sales_Existing)
  LOAD * RESIDENT Sales_Delta;
  DROP TABLE Sales_Delta;

  // Store merged result back to QVD
  STORE Sales_Existing INTO [lib://QVDs/sales.qvd] (qvd);
  DROP TABLE Sales_Existing;

END IF

// Step 2: load from QVD into the model (always optimized)
Sales:
LOAD * FROM [lib://QVDs/sales.qvd] (qvd);

// Step 3: record the max timestamp for next run
MaxDate:
LOAD Max(UpdatedAt) AS UpdatedAt RESIDENT Sales;

Buffer LOAD is a built-in Qlik caching mechanism. On first run, data is loaded from the source and cached in a temporary QVD file. On subsequent runs within the defined stale window, Qlik reads from the cache - not from the source.

// Standard LOAD - hits source every time
DimProduct:
LOAD ProductID, ProductName, Category, UnitCost
FROM [lib://Sources/products.csv];

// Buffer LOAD - caches for 7 days
// After 7 days, Qlik automatically invalidates and reloads from source
Buffer (stale [7 days]) DimProduct:
LOAD ProductID, ProductName, Category, UnitCost
FROM [lib://Sources/products.csv];

// Ideal for: slowly-changing dimensions (products, regions, cost centers)
// Not ideal for: rapidly changing data (stock prices, real-time sales)

// Buffer LOAD also works with database connections:
Buffer (stale [1 day]) DimRegion:
SQL SELECT RegionID, RegionName, Country, TimeZone FROM dim_region;

Binary LOAD imports the complete data model of another Qlik app - all tables, all fields - without re-running any script. Ideal when multiple apps share a common dimension layer.

// In the secondary app - load everything from the primary:
Binary [lib://Apps/MasterDimensions.qvf];

// After Binary LOAD, all tables from the primary app are available.
// Only load the specific fact tables this app needs:

FactSalesRegion:
LOAD RegionID, ProductID, Amount, SaleDate
FROM [lib://QVDs/fact_sales_region.qvd] (qvd);

// This model instantly inherits DimProduct, DimCustomer,
// DimRegion, DimDate from the primary app - no reprocessing.

LOAD Ordering - Reduce Passes Through the Data

In Qlik, when you LOAD a table preceded by a derived LOAD (using the result of the previous LOAD), the engine has to make two passes. When possible, combine calculations into a single LOAD to minimize passes.

// First pass: load raw fields
T1:
LOAD SaleID, Amount, Discount FROM sales.csv;

// Second pass: derive NetAmount from T1
// Qlik reads the resident table again
T2:
LOAD
  SaleID,
  Amount,
  Discount,
  Amount * (1 - Discount) AS NetAmount
RESIDENT T1;
DROP TABLE T1;

// Single LOAD - derive NetAmount on the fly
// No RESIDENT intermediate table needed

Sales:
LOAD
  SaleID,
  Amount,
  Discount,
  Amount * (1 - Discount) AS NetAmount
FROM sales.csv;

// One pass over the source.
// Fewer resident tables = less RAM overhead.

Engine Diagnostics API

The Qlik Engine REST API exposes detailed profiling data for each app. This endpoint reveals which expressions consume the most time and RAM - the starting point for targeted optimization.

// Engine API - app profiling (Qlik Sense Enterprise)
// Authenticate and get app session:
GET https://<qlik-server>/api/v1/apps/{appId}/evaluations

// Or use the Engine JSON API (WebSocket):
{
  "method": "Global.GetDocList",
  "params": {}
}

// Request object properties including layout calculation time:
{
  "method": "Doc.GetObject",
  "params": {
    "qId": "chart-object-id"
  }
}

// In Qlik Cloud, use the dedicated profiling endpoint:
GET https://<tenant>.us.qlikcloud.com/api/v1/apps/{appId}/diagnostics
// Returns: calculation time per object, cache hit rate,
//          memory consumption per table and field

TRACE Timing Markers in Script

Add TRACE markers with timestamps directly in your reload script. The output is visible in the reload log and allows you to pinpoint exactly which table or transformation is causing slow reloads.

// Pattern: timestamp before and after each major table load

// ===== SECTION: SALES FACT TABLE =====
LET vT0 = Now();
TRACE === START: Loading FactSales ===;

FactSales:
LOAD
  SaleID, CustomerID, ProductID, Amount, SaleDate
FROM [lib://QVDs/fact_sales.qvd] (qvd);

TRACE === DONE: FactSales - $(QvdNoOfRecords('lib://QVDs/fact_sales.qvd')) rows, time: $(Interval(Now() - vT0, 'mm:ss')) ===;

// ===== SECTION: CUSTOMER DIMENSION =====
LET vT1 = Now();
TRACE === START: Loading DimCustomer ===;

DimCustomer:
LOAD CustomerID, CustomerName, Segment, Region
FROM [lib://QVDs/dim_customer.qvd] (qvd);

TRACE === DONE: DimCustomer - $(NoOfRows('DimCustomer')) rows, time: $(Interval(Now() - vT1, 'mm:ss')) ===;

// Check the reload log to see which section is slowest.
// If FactSales takes 4 minutes and DimCustomer takes 2 seconds,
// incremental load for FactSales will give you the biggest gain.

Performance Audit Checklist

• ⚠️
  Check for synthetic keys monthly. Open the data model viewer. Any table named $Syn* is a synthetic key. Resolve with aliasing or a mapping table.
• ⚠️
  Audit unused fields quarterly. Cross-reference all loaded fields against expressions and master items. Every orphaned field is wasted RAM.
• ⚠️
  Scan for IF() inside aggregations. Use text search in the app editor for Sum(IF, Count(IF, Avg(IF. Replace with Set Analysis.
• ✅
  Verify incremental load is working. Compare row counts in reload log: if full reload rows equals incremental rows every run, delta detection is broken.
• ✅
  Review sheet object count per sheet. Anything over 12 objects warrants splitting into sub-sheets or using a container.
• ✅
  Confirm QVD layer stale times are appropriate. Dimension QVDs cached for 7 days? Fact QVDs refreshed daily or hourly? Validate business requirements match the refresh schedule.
• ℹ️
  Document TRACE markers in every production script. Makes diagnosis faster when a reload slows down after a schema change.
• ℹ️
  Test expression response time after major data volume increases. An expression that runs in 2 seconds at 5M rows may take 18 seconds at 50M rows - especially AGGR() in charts.