Qlik Community

QlikView App Development

Discussion Board for collaboration related to QlikView App Development.

Announcements
The #1 reason QlikView customers adopt Qlik Sense is a desire for a modern BI experience. Read More
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor

Optimised load and UI performance in charts

Hi all,

This is basically to understand one of the statements I came across in a qlikview blog.

I know that optimized qvd affects the QVW load/reload time. I read : Optmized QVD will affect UI performance.

So, my question is: Will a chart in a optimized loaded QVW load faster then in a QVW which is non-optimized loaded.

16 Replies
Highlighted
Specialist III
Specialist III

hello

optimize and non-optilize has meaning only for the load phase

once it is loaded in memory, no matter how it was loaded (optimized or not)

Highlighted

Where exactly did you read this? Would you be able to share a link to this?

Highlighted
Contributor
Contributor

The excerpt is : Yes, an unoptimized load can affect the runtime performance of your qvw. Unoptimized loads frequently cause numbers to be converted to strings, which generally will perform slower in the qvw.

Highlighted

Can you share the link please?

Highlighted
MVP & Luminary
MVP & Luminary

Loading optimized or not will have no impact to the datatypes of numbers or strings - they are loaded like they are unless you does any transforming on it.

- Marcus

Highlighted

Is this where you got it from?

QVD optimization and hashing | Qlik Community

rwunderlich‌ does this still hold true?

Highlighted
Contributor
Contributor

Highlighted
MVP & Luminary
MVP & Luminary

I must a bit correct my statement from above. In general it's true unless the value isn't really a number else a dual-value and has beside the numeric value also a string-representation which is either directly stored on a field-value level or within the qvd meta-data (if for a field only one format exists the format is stored within the header else each value is directly stored).

In the case of an unoptimized load the formatting is applied. If the field is a dual-field and has more as one formatting than will the formatting also by an optimized load considered.

Today a number will be stored within a qvd and within a qvw handled with 8 bytes and a dual-date with 20 bytes. You could check this with a small routine like this:

t:

load

    recno() * 2  as ID,

    Date(makedate(2000) + ceil(rand() * 1460), if(mod(recno(), 2)=0, 'DD.MM.YYYY', 'YYYY-MM-DD')) as Date

    //floor(makedate(2000) + ceil(rand() * 1460)) as Date

autogenerate 1000000;

store t into t.qvd (qvd);

drop tables t;

t:

load * from t.qvd (qvd)

//where year(Date) > 2000

;

by looking on the filesizes within your storage and by looking into the mem-files from the qvw and the xml qvd-header like here:

More background to this could you find here: ByteSizes from Values in QlikView

- Marcus

Highlighted
MVP & Luminary
MVP & Luminary

Still mostly true.  Although I would edit my claima bit.  It sounds like a I'm saying string operations would be used on the field -- which I may have believed at the time -- thinking they were only strings and not duals, which they are (duals).  So the impact of conversion caused by an un-optimized load is an increased memory requirement, which can have a small impact on performance. 

You can find these converted fields and measure the memory impact using the Recommendations sheet of Document Analyzer.  Some people I know are obsessive about it ("no un-optimized loads!").  I don't worry about it too much but fix the  big ones to recover the memory.

-Rob