Rule size is limited?

[macsir]

I have created a rule is is more than 1000 rows in rule sheet. When I saved it to server, it says " Maximum size of rule reached: 533".
Dose that mean the rule file size is limited? or words in rule are limited?

[macsir]

Looks like I have too many nested if in the formula? Is the number of "IF" limited?

[RJ!]

Have you tried to paste the rule in via Perspectives/ Architect instead of Excel?

[macsir]

Have you tried to paste the rule in via Perspectives/ Architect instead of Excel?

Tried but same error. I think the number of nested if is limited. I resolved it by splitting them into another measure.

[Alan Kirk]

Have you tried to paste the rule in via Perspectives/ Architect instead of Excel?

Tried but same error. I think the number of nested if is limited. I resolved it by splitting them into another measure.

It is, but I'm stuffed if I can find it in the documentation anywhere. The documentation does mention that there is a limit of 20 nested If() functions in TI processes. (Page 244 of the 10.1 Reference Guide.) However it's silent on the corresponding limit in rules (page 128), nor can I find any limit mentioned in the Rules guide.

However experimentation in 10.1 suggests that the limit is 30. (And actually, that does sound familiar from somewhere previously.) I nested a bunch of If() statements in an .xdi and it was OK up to the 30th one. As soon as I added a 31st one I got an error but it was not a Maximum Size Reached error; it was a Stack Overflow error. I pushed the expression up beyond the mystical 1024 character limit (which, if I had to make an educated guess, is where I'd expect troubles to kick in) and it was fine... as long as I didn't go over 30 nested If() statements. As soon as I did, I got the error, even if I tweaked the expression to be shorter than the one that compiled with 30 If()'s. Accordingly while there is such a limit, I'm not sure that it was that that was triggering your error in this case. Your split probably cleared another error.

That having been said, if you get to 30 nested if() functions it's probably time to reconsider the design.

[macsir]

Have you tried to paste the rule in via Perspectives/ Architect instead of Excel?

Tried but same error. I think the number of nested if is limited. I resolved it by splitting them into another measure.

It is, but I'm stuffed if I can find it in the documentation anywhere. The documentation does mention that there is a limit of 20 nested If() functions in TI processes. (Page 244 of the 10.1 Reference Guide.) However it's silent on the corresponding limit in rules (page 128), nor can I find any limit mentioned in the Rules guide.

However experimentation in 10.1 suggests that the limit is 30. (And actually, that does sound familiar from somewhere previously.) I nested a bunch of If() statements in an .xdi and it was OK up to the 30th one. As soon as I added a 31st one I got an error but it was not a Maximum Size Reached error; it was a Stack Overflow error. I pushed the expression up beyond the mystical 1024 character limit (which, if I had to make an educated guess, is where I'd expect troubles to kick in) and it was fine... as long as I didn't go over 30 nested If() statements. As soon as I did, I got the error, even if I tweaked the expression to be shorter than the one that compiled with 30 If()'s. Accordingly while there is such a limit, I'm not sure that it was that that was triggering your error in this case. Your split probably cleared another error.

That having been said, if you get to 30 nested if() functions it's probably time to reconsider the design.

Thanks for sharing, Alan. I think if we really need to have more nested if, we can use CONTINUE to split them into two formulas, right?

[Alan Kirk]

Thanks for sharing, Alan. I think if we really need to have more nested if, we can use CONTINUE to split them into two formulas, right?

That should work, but honestly at that point I'd be considering seriously whether something like lookup cubes or attributes might be a better approach.

[ioscat]

i'm not sure but IF statement is highcost function to calculate, so if you can find some aroud way - you ought to use it. Am I right?

[Alan Kirk]

i'm not sure but IF statement is highcost function to calculate, so if you can find some aroud way - you ought to use it. Am I right?

Possibly, and possibly not.

For some reason I'm calling to mind an article that I read recently, and now have the words of Jeff Atwood (of StackExchange fame/infamy) pounding in my head:

All that's left is micro-optimization, and the minute you begin worrying about tiny little optimizations, you've already gone down the wrong path.

As he in turn quoted from Bill Murray in the movie Meatballs:

It just doesn't matter! It just doesn't matter!

I don't know whether anyone has ever run a test on how long an If() takes to execute (and you can bet that this will be different in a TI than in Rules, since they're entirely different creatures) but my bet is that for a single If(), or even a couple of nested if()s, it won't be much. If the difference between a single If() and an alternative method is in milliseconds, then you'll probably have spent more time worrying about the optimisation than you'll ever gain by making it. But when you're getting beyond (or even to) 30 If()s per cell, it's not the if() function itself that's the problem. There are in fact two problems.

The first is the multitude of them that need to be evaluated for any given value. If I may paraphrase Col. Bernd Von Kielst:

The server processor in processing If() functions is like an elephant attacking a host of ants. The elephant will kill thousands, perhaps even millions, of ants, but in the end their numbers will overcome him, and his performance will be eaten to the bone.

That having been said it may also to some extent depend on how If() is coded internally, which I don't have an answer to. If it evaluates from outside in and stops when it hits the first True condition, and if the majority of the evaluations will be amongst the first few of the statements then again... it probably doesn't matter.

If, on the other hand, it acts like .Net's IIF() function and always evaluates both True and False conditions regardless then we're back to ants and elephants.

But the second problem is another issue that Atwood raised:

Stop micro-optimizing and start macro-optimizing: per Lippert, code that makes sense is code which can be analyzed and maintained, and that makes it performant.

One of the reasons that I like using .xrus for rules is that they let me break out the True and False blocks of an If() function and use colour coded rows to indicate where the True and False parts of the code occur. However even using that technique I find it difficult to believe that n blocks of code each containing 30 If() functions will be particularly easy to analyse and maintain. A new admin trying to figure out how the code flows from that (or who tries to make a change to the code and then has to use 30 different highlighters and a magnifying glass to work out where s/he missed a bracket) is likely to suspect that Dante might have neglected to describe one of the circles of Hell. If the code is difficult and time consuming to understand, update and maintain... then it's probably time to look for different code.

[tomok]

Rules are like chocolates, eaten in moderation they can be wonderful. Too many and they they can be hazardous to your health. My advice to new TM1 people is just because you can do something with a rule doesn't mean you should. There is a cost to every rule written, in terms of performance. You just have to decide which ones are worth paying for and which ones aren't.

[David Usherwood]

Finally I realise why I like writing rules . I used to think I liked the challenge, the search for elegance and simplicity, the traceability, the happy customers - but it's really just the chocolate rush....

[macsir]

Thanks, everyone for the sharing. I totally agree with you guys. Be careful to write every rule in terms of performance but in some cases, you have to use nested IFs if you can't figure out other ways plus the current performance is not bad. In my case, this largest nested IF has more than 400 rows in rule sheet and it calcualtes 25 scenarios in its all sub IFs. The performance is still good.