Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
.png "Former Employee"){kind=icon}
Although QlikView 5 was a stable, good version with lots of functionality, it wasn’t good enough for the new hardware that came along. We had already seen the arrival of the 64-bit Itanium processor and we had responded by developing an Itanium edition. So far, so good. But when we experimented with large data amounts, we realized that although QlikView now could load and address very large amounts of data, QlikView couldn’t process the data fast enough. QlikView needed more processor power. The amount of memory was no longer the limiting factor – instead it was the processor power.
About this time, Intel had just launched its first dual core processors. There were already multi-processor motherboards, but the dual core processors were cheaper and could in addition share cache. The introduction of the dual core processors and QlikView’s need for more processor power forced us to look at how we better could utilize parallel processing.
Hence: Time for a re-write! Multi-threading – here we come.
Already in the QlikView 5 server, there was some basic multi-threading: Each session was evaluated in its own thread. But now, we needed to take multi-threading several steps further; we needed to make the evaluation of every click multi-threaded.
Multi-threading is not easy. The software process needs to have mechanisms that can determine that one thread should be split into several, and other mechanisms that merge several threads into one. The threads are asynchronous and sometimes a thread needs to stop and wait for the result of another thread. This means that you can get situations where two threads wait for each other. So you also need mechanisms to avoid such deadlocks.
Anyway, we re-wrote large parts of the code and when we released QlikView 6 in the spring of 2003, it was multi-threaded.
In the solution, the logical inference for a single click is multi threaded and the evaluation of several threads are merged together to form the final result. After the logical inference, the sheet objects need to be calculated. Each object is then a thread of its own that subscribe to all changes in the data model. “Subscribe” means that it is re-evaluated every time there is a change in the selection state. In addition, the chart engine is multi threaded, so that if an aggregation is made over a table with a large number of records, different parts of the table are aggregated in different threads.
QlikView 6 also brought the LEF files, which enabled Client Access Licenses (CALs) for the server. It also brought the qvp protocol, the plug-in client, the OCX, the table viewer, copy and paste objects, the layout themes, semi transparency (GDI+), the color functions, variables in the layout, the grid chart, the gauge chart, the radar chart, the slider object and the language dll:s.
We also introduced different license levels for the stand-alone version of QlikView 6: Enterprise, Professional and Analyzer, so that a customer could have different capabilities for developers, power users and standard users.
QlikView 6 should be remembered for bringing the multi-threading that we use still today. This is the core of the modern QlikView that can use the power of today's multi-core hardware.
Further reading on the Qlik history:
A Historical Odyssey: QlikView 5 and the Rainbow Border
A Historical Odyssey: QlikView 7, QVD files and the Aggr() function