Slow reload times for QlikView using QlikView desktop
Afternoon,
I would appreciate some insight from those who have a better understanding of the internal processing of QlikView than I do.
The largest model in our environment is rebuilt everyday via a scheduled task in QMC. It takes around 40 minutes to rebuilt.
When I open that same model using QlikView Desktop and build the model it can take up to 1:30 depending on other processing that is been done on the server. I tested the rebuild and ran it when there was no other activity on the system (after working hours). It still takes over 1 hour to build.
I am puzzled as to why there is such difference in the build times using these 2 methods of rebuilding, as I assume they have the same processing engine. I am running my desktop rebuild on the same server that runs QMC. I log onto that server using a remote desktop connection. We also only have 1 instance of QMC running on that server. I have carried out this exercise as well as once of my colleagues and get the same results.
I am using May 2023 version of QlikView.
I would appreciate some insight into why this is happening.
Hi, you can take the reload log when the server does the reload, and compare with the desktop reload log file. There you can see if the time is higher in every sentence, or if there is only one or few sentences were the reload time is higher
I would start by looking at the script log for both reloads. In particular, the log line:
EnableParallelReload 1
Compare the two logs to see if the time difference is in a particular step or spread out evenly across multiple steps. You can easily compare the steps of both logs using my free Script Log Analyzer tool
Thanks Rob, I will download your free tool and see what it says. I did manually import the 2 log files into a spreadsheet and compare. Both have EnableParallelReload 1. The only difference I can see is:
Desktop
Time
Descrition
Server
Time
Description
20250822
15:04:33
QlikView Desktop Version 12.80.20000+2023-05-10 12:47:02+efc646f
24/08/2025
03:30:09
QVB Version 12.80.20000+2023-05-10 12:46:57+efc646f
20250822
15:04:33
Reload Executed By Universal\User Name
24/08/2025
03:30:09
Reload Executed By WH-UNISUN02\Local.account
20250822
15:04:33
Process Executing QlikView Desktop
24/08/2025
03:30:09
Process Executing QVB
20250822
15:04:33
Process ID 588172
24/08/2025
03:30:09
Process ID 221576
From what I can see on an initial inspection is there is a gap the start at a pint in the reload and progressively gets worse. I first reload all the dim tables and then the fact, so it starts with the facts. Will use your tool to see what the differences are.
Between the reload on the server per qvb.exe and the desktop per qv.exe is a significantly difference in regard to the UI. The qvb.exe doesn't initialized the UI and performed only a refresh of the data while the qv.exe opened the UI completely especially including to build the data-model. By larger and/or more complex data-models, enabled indexing, ... such processing may need some time.
Beside this I have the impression that your task is single-stage. If so I suggest to consider to implement a multi-stage (raw-data --> transform-data --> data-model --> report (binary load)) approach with an appropriate incremental logic.
Morning, thanks to everyone who has posted in this question. On further investigation on the issue, I have compared the log file created by the .qvb and the desktop. While there are minor differences between the 2 when loading dims and .qvds, the largest difference seems to stem when loading the large fact tables using a resident load. We reload our largest fact and create a few summerised tables with subtotals and counts. The helps when creating some tables where we only need to reference the filed in the summerised table and not have to recalculate the total while rendering the graphic. These resident loads therefore use a group by and sum or count function
Is there a logical reason why these would take longer when running from the desktop version?
From an engine point of view both (server and desktop) should be perform quite equally (with the same release and on the same machine with not much parallel running stuff).
Therefore the most likely reason are any differences within the configurations. Beside the already hinted EnableParallelReload there may also other settings having an impact like the MaxCoreMask, ScriptMode, EnableFlushLog and probably some more. Beside the Script-Log you may also look into the settings.ini if any have a different values and/or are missing on one side (means mostly that not there listed defaults are used).
Further helpful would be to monitor the resource-consumption during the execution (when the extracts and aggregations begins) within the task-manager. If the RAM consumption is quite near of the limit of the machine the difference may be the loaded UI by causing a RAM swapping. Another look should go to the core-consumption - maybe the server takes twice as much as the desktop. Or there are any other anomalies.
In regard to the resource-consumption there may also any OS and/or VM differences between scheduling I/O between the cores in regard to an active user-session and running a service in the background.
Thanks Marcus, I will check those setting. I have looked at the setting before, but this is a new area so may take some time to do it. From a server perspective, we not running a VM, and both builds are being done on the same server. I do not believe that memory is an issue as the server runs at just over 50% of available memory. When I do my desktop build I did it when users are logged off so there would be even more available during my test. I did notice that the qvb.exe runs at 'below normal' priority while QV runs at 'Normal'.
I did ask a colleague to build the model and he got the same results as me. Just wanted to eliminate the possibility of a config issue on my desktop version.
I will check the .ini files and other setting and revert.
I have looked at the .ini and settings and could not pick up any difference between the qvb.exe and qv.exe parameters.
I experimented and ran both builds at the same time and monitored the difference in resource monitor and in task manager. The qvb.exe build finished in 36 minutes while the QV.exe build finished in 1:55 minutes. I noticed the following differences. The qvb.exe ran at below normal priority, while qv.exe ran at normal priority. The other difference was the qvb.exe ran with 'elevated' set to yes while qv.exe it was set to no. The cpu time for each process also differed, with qvb.exe using 00:03:14 while the qv.exe used 00:04:30. This does not seem logical, but those are the reported measures. My understanding of 'elevated' refers to whether a process is running as administrator. I ran, on two occasions, qx.exe as the administrator. These jobs finished in 00:44:00, slightly longer than the qvb.exe process, but a significant reduction to it's previous build.
Can anyone explain why qv.exe builds faster when run as administrator?
