Hello,
I have been reading posts on the speed of TM1 can be increased if we tighten up the feeders...What exactly does that entail ?
Can anyone give me an example of a good feeder and a bad feeder ?
What does tightening up of feeders mean?
Re: What does tightening up of feeders mean?
When you are feed from one cell to another you are saying: "If this cell has a value, then calculate this other cell"...
The reason that you have feeders is so that you can turn all calculations off, and then pick which cells you want to be calculated with the use of feeders (to improve performance, calculating every cell is not good on performance).
A bad feeder is one that feeds another cell (ie asks for it to be calculated) even when there is no calculation required, for example:
You have a rule A = B*C and your feeder is B => A, if B always has a value then A will always be calculated. If C rarely has a value then you should have made C feed A instead, as then A would only rarely be calculated.
Another example: You have a rule that only applies for the Month of June, July and August however you feed it with the All Months consolidation because i may be easier to type out. Even if June, July and August didn't require calculations, they would still be calculated if any other Month had a value.
There is a trade off between feeding for optimization and the amount of time you have to spend writing the rules.
The reason that you have feeders is so that you can turn all calculations off, and then pick which cells you want to be calculated with the use of feeders (to improve performance, calculating every cell is not good on performance).
A bad feeder is one that feeds another cell (ie asks for it to be calculated) even when there is no calculation required, for example:
You have a rule A = B*C and your feeder is B => A, if B always has a value then A will always be calculated. If C rarely has a value then you should have made C feed A instead, as then A would only rarely be calculated.
Another example: You have a rule that only applies for the Month of June, July and August however you feed it with the All Months consolidation because i may be easier to type out. Even if June, July and August didn't require calculations, they would still be calculated if any other Month had a value.
There is a trade off between feeding for optimization and the amount of time you have to spend writing the rules.
-
paulsimon
- MVP
- Posts: 808
- Joined: Sat Sep 03, 2011 11:10 pm
- OLAP Product: TM1
- Version: PA 2.0.5
- Excel Version: 2016
- Contact:
Re: What does tightening up of feeders mean?
Telula
If you check the TM1 Rules Guide which is part of your documentation, you will find that it has various examples of rules and their feeders.
There are typically many tens of thousands of base level cells in a TM1 cube, eg 5000 branches x 200 products x 144 months x 20 versions, etc. TM1 only allows entry of data at the base level, and then very efficiently consolidates it up the hierarchies in each of the dimensions. Before Rules, TM1 only consolidated cells for which a non-zero value had been entered. This makes the consolidation much more efficient. However, as soon as you introduce Rules, TM1 needs to check every possible base level cell to see if it could get a value from a Rule that needs to be consolidated, eg for
[‘Sales’] = N: [‘Units’] * [‘Price’];
it would need to check every cell for Sales to see if the calculation would give a value. This works but takes a long time to consolidate, since TM1 must evaluate the rule for every possible base level cell combination. It can lead to an explosion in the size of the cube. You therefore need to add the SKIPCHECK statement. This tells TM1 not to check to see if a rule will deliver a non-zero. The problem then is that you see 0 for top level sales. The answer is to write a FEEDER statement, eg [‘Units’] => [‘Sales’] ;. This effectively says that a non-zero value for Units implies that there will be a non-zero value for Sales. Internally TM1 stores a marker that tells it to evaluate the rule for Sales in combination with the other elements, eg Branch XYZ, in Feb 2008, for Product 22, which sold 5000 units at £4.99.
This is a very simple example. Feeders can get much more complex. Over-feeding can result in an explosion in cube size and slow calculation. Under-feeding can result in incorrect results, generally but not always a zero at consolidated level.
Consider an allocation:
['HO Overhead'] = N: ['HO Branches','Overhead'] * ['Sales'] \ ['Business Branches','Sales'] ;
I could feed this like this:
['HO Branches','Overhead'] => ['Business Branches','HO Overhead'];
Feeding the consolidation Business Branches would feed HO Overhead for all Branches below it, but many Branches might not have any sales, so I would be telling TM1 to evaluate a lot of HO Overhead calculations that would give a zero result.
A better feeder would be:
['Sales'] => ['HO Overhead'] ;
This will only make TM1 calculate and consolidate HO Overhead, when there is a value for Sales in the Branch.
Another piece of advice is to consider whether you need a rule. In some cases rules are the best approach. However, if you do not need the ability to instantly see the impact of a change in a value on other values, then consider doing the calculation in a TI process instead.
Regards
Paul Simon
If you check the TM1 Rules Guide which is part of your documentation, you will find that it has various examples of rules and their feeders.
There are typically many tens of thousands of base level cells in a TM1 cube, eg 5000 branches x 200 products x 144 months x 20 versions, etc. TM1 only allows entry of data at the base level, and then very efficiently consolidates it up the hierarchies in each of the dimensions. Before Rules, TM1 only consolidated cells for which a non-zero value had been entered. This makes the consolidation much more efficient. However, as soon as you introduce Rules, TM1 needs to check every possible base level cell to see if it could get a value from a Rule that needs to be consolidated, eg for
[‘Sales’] = N: [‘Units’] * [‘Price’];
it would need to check every cell for Sales to see if the calculation would give a value. This works but takes a long time to consolidate, since TM1 must evaluate the rule for every possible base level cell combination. It can lead to an explosion in the size of the cube. You therefore need to add the SKIPCHECK statement. This tells TM1 not to check to see if a rule will deliver a non-zero. The problem then is that you see 0 for top level sales. The answer is to write a FEEDER statement, eg [‘Units’] => [‘Sales’] ;. This effectively says that a non-zero value for Units implies that there will be a non-zero value for Sales. Internally TM1 stores a marker that tells it to evaluate the rule for Sales in combination with the other elements, eg Branch XYZ, in Feb 2008, for Product 22, which sold 5000 units at £4.99.
This is a very simple example. Feeders can get much more complex. Over-feeding can result in an explosion in cube size and slow calculation. Under-feeding can result in incorrect results, generally but not always a zero at consolidated level.
Consider an allocation:
['HO Overhead'] = N: ['HO Branches','Overhead'] * ['Sales'] \ ['Business Branches','Sales'] ;
I could feed this like this:
['HO Branches','Overhead'] => ['Business Branches','HO Overhead'];
Feeding the consolidation Business Branches would feed HO Overhead for all Branches below it, but many Branches might not have any sales, so I would be telling TM1 to evaluate a lot of HO Overhead calculations that would give a zero result.
A better feeder would be:
['Sales'] => ['HO Overhead'] ;
This will only make TM1 calculate and consolidate HO Overhead, when there is a value for Sales in the Branch.
Another piece of advice is to consider whether you need a rule. In some cases rules are the best approach. However, if you do not need the ability to instantly see the impact of a change in a value on other values, then consider doing the calculation in a TI process instead.
Regards
Paul Simon