Does the IF-statement evaluate whole expression?

[NicolaiF]

Hi Qlik Community,

I am working with an app which is running slow - Thus, I am trying to optimize its performance.

I regognized that I could maybe condition some of my measures, so that if nothing is selected, the measure returns 0 by default and skipping the actual expression. However, It seems like the whole expression is evaluated regardless?

The example underneath shows the structure of my measure.

IF(GetSelectedCount(Field)=0, 0, [Expression])

I would expect that Qlik simply evaluates the condition (GetSelectedCount(Field)=0) and returns 0 and skipping the Expression.

However, when putting in a heavy expression my measure takes a long time to evaluate - even though GetSelectedCount(Field)  is equal to 0. 

Does anyone know how the IF-statement is eveluating its input?
Does anyone know a workaround to achieve what I am trying to do?

[martinpohl]

it is better to use the calculation condition than in expression

Regards

[NicolaiF]

I would do that, but I am using my measures in Text And Image objects and not KPI's, so it doesn't look like Calculation Condition is available.

[marcus_sommer · Accepted solution]

Yes, an if-loop in Qlik evaluates always all branches. It's not an error else a design-decision - which has some benefits as well as disadvantages ...

Workarounds could be like already mentioned conditions for the expression or maybe the visibility of the objects - means you need at least two of them. Further you could also use a table-chart instead of the textbox - it doesn't need mandatory any dimension and with some layout-adjustment it looks like a textbox.

Another way to reduce the calculation-times might be to include the condition within the expression in a set analysis.

But I think in your case you might also replace the if-loop with something like this:

pick(sign(GetSelectedCount(Field)) + 1, 0, [Expression])

- Marcus

[sunny_talwar]

May be look here https://community.qlik.com/t5/QlikView-Scripting/help-performance-improvements/m-p/626750#558313

An alternate would be to use Pick(Match())

[NicolaiF]

I think
                     pick(sign(GetSelectedCount(Field)) + 1, 0, [Expression]) 

would solve the example I stated in the question. 
However, my actual measure contains several IF-statements.. I am not sure if your solution would be able to solve that as well?

My actual measure looks like the example below:

IF(GetSelectedCount(Field1)=1, [Expression1]
IF(GetSelectedCount(Field2)=1, [Expression2]
IF(GetSelectedCount(Field3)=1, [Expression3],
[Expression4])))

Sorry for not claryfying that in the original question. 

[sunny_talwar]

May be try like this

Pick(
  Match(1
    , GetSelectedCount(Field1)
    , GetSelectedCount(Field2)
    , GetSelectedCount(Field3)
  ) + 1
, [Expression4]
, [Expression1]
, [Expression2]
, [Expression3])

[NicolaiF]

It looks like this actually works.
However, as with the nested IF-functions, it still looks like it evaluates alle the expressions.
Also, it doesn't seem to improve performance enough to notice.

[marcus_sommer]

I think you could apply the same main-logic with something like:

pick(-rangemin(
(GetSelectedCount(Field1)=1)*3,
(GetSelectedCount(Field2)=1)*2,
(GetSelectedCount(Field3)=1)*1) + 1, 'exp4', 'exp3', 'exp2', 'exp1')

In general you need only a smart logic to control the pick-return and there are even more complex logic possible.

Beside this you could like above mentioned also use a table-chart - see here the last answer in the post to get an idea what's meant: bold-for-the-particular-text-in-the-text-box.

- Marcus

[marcus_sommer]

Like explained in the link which Sunny has provided behaves match() identically with if() in regard of evaluating at first all branches and checking the condition afterwards. I never tested it but I believe pick() behaved differently and just returned the n parameter - if I'm right you should notice it.

- Marcus