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.
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:
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
store t into t.qvd (qvd);
drop tables 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:
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.