TM1 Forum

Hi all,

I have a question pertaining to the impact of feeders in STET cells. Let's say feeders are written in a Source cube and rules are written in a Target cube that pulls data from the Source cube.

Assuming the Actual version in Target cube will be STET so that the rules after STET do not apply.

['ACTUAL'] = N: STET;

Hence, all cells with Actual version will be STET.

The feeder in Source cube is something like this:
['Measure ABC'] => DB('Target Cube', blah, blah....!Version, 'Measure XYZ');

So the feeders will apply to every version, including Actual.

So the question is: since cells with Actual version in Target cube is STET, will the feeder markers be inserted into these cells since the feeder in Source cube includes Actual version? I'm looking at reducing memory usage by applying STET, and am wondering if this will also help to reduce memory usage by negating the feeder.

Many thanks in advance!

I don't know the answer for sure, probably only one of the legacy programmers from Applix will know for sure, but I highly doubt the feeders logic is smart enough to know that the rule for a cell has been stetted out. The rule is totally independent of the feeder. They are two different steps in the process of getting a cube to work properly. I just can't imagine they programmed in logic to say, "hey, the rule for this cell has been stetted out so we can skip the feeder marker on this one". Just don't see it.

thanks for your reply, tomok.

I was kinda hoping that the act of STET-ing the cells not only tells TM1 not to apply subsequent rules, but will also remove all feeder markers (since rules don't apply anymore). Then the sparse consolidation algo will just try these cells as "normal" and consolidate up.

the thing is, it is harder to write precise feeders compare to rules, hence resulting in overfeeding => more memory usage.

I have a similar issue, I have a rule that only applies to input Currencies (iUSD, iCAD), I am excluding the reporting currency USD
In this code below I just wanted to check which feeder is recommended. I have STET on the reporting currency USD.
Am I feeding USD in my first feeder?

SKIPCHECK;

['Currency':'USD']= N: STET;
['Account':'4556'] = N: ['Account':'5644'] * 1.25;

FEEDERS;
['Account':'5644'] => ['Account':'4556'];
OR
['Account':'5644','Currency':{'iUSD','iCAD'}] => ['Account':'4556'];

I agree with Tomok, I think TM1 feeds anything you ask it to feed, without considering the rule at the fed intersection. It will then evaluate all fed rules in a separate step, and those that evaluate to STET will be left as input cells.

You can observe this by considering the RAM utilization of the feeders under the various scenarios. There's also logic in is, as the cost of evaluating every rule during the feeding phase would outweigh the RAM consideration, especially since more careful design will avoid the situation.

In the example listed it would be better to exclude Actual by changing the LHS or a slightly worse option would be to make the RHS conditional on ~'Actual'

If this will make much difference in RAM usage I'm unsure. In relative terms to everything else the feeder flags are tiny. What I'm not sure about is if having zero input cells flagged has an impact on performance or RAM.

I can see that there could be a performance impact since time is wasted adding zeros up into consolidations.
What I don't know is a unfed null cell an different to a fed null cell in terms of RAM, though a test could be devised. My feeling is that fed null cells are no different to unfed null cells.
If you have rules / feeders running from your Actual then there will be an impact there too.

Cheers,

Steve, my understanding, which I have absolutely no proof for, is that feeding in TM1's internal terms really means creating branches in the binary tree, which is used as the structure for cube data. If you create branches with no data sitting on them it has an impact on both the performance (because the branch has to be traversed in search for values anytime a consolidation is performed) and the memory consumption (because even though there is no data on that branch, its full address needs to be stored in memory just as though there was a value there).

You can think about a case when you put a value into a previously empty cell. This "feeds" the cell, therefore creating the branch for it. If you subsequently delete the value, the branch will stay there, having a tiny impact on performance and memory consumption alike. Having very many cells like that will have a noticable impact on performance and memory until the cube is reloaded and the binary tree rebuilt.

If you think about it, this exact design principle is what makes TM1 deal with sparsity so well - if you don't put a value in a cell or don't feed that cell then it doesn't have an impact on anything, because it doesn't really exist in the underlying internal structures.

PS: And as a side note, the binary tree concept is why the dimension order can have such a significant impact on the memory consumption and, to a lesser degree, on the performance. Basically a tree is optimal in terms of overhead memory allocated purely to storing addresses of all memory cells (as opposed to storing real data) if it has a thin trunk and a thick crown, not vice versa, which equals to having small/sparse dimensions first and big/dense dimensions last.

PS2: The tree structure used by TM1 is most likely not really a binary tree per se, but probably another type of tree nonetheless. I am using the term "binary tree" just because it is the type of data tree I am most familiar with.

I know the example is for unfed data cells but for ruled cells a feeder is a single bit and the full RAM usage of the cell isn't consumed until the ruled value is calculated.
Assuming input cells work the same way, I can see the performance hit of fed nulls but the RAM hit ought to be v small, subject to the level of overfeeding.

(Back in the day a populated cell and a feeder used up the same amount of RAM and I can remember Applix making a big deal that feeders were now single bit, it did make a big difference.)

Cheers,

Steve, I am almost sure (and a number of tests posted on this forum seems to confirm it) that even now feeders use up much more than 1 bit of RAM per each fed cell. I would say that maybe there is 1 bit of data sitting in a cell as opposed to the 32-bit (?) value "normally" stored, but this does not take into account the memory that is used for addressing. I would say the difference in how much memory is used by a fed cell is highly dependent on how (un)optimal addressing in that cube is, which depends on the number of dimensions and their order. In your average-to-worst-case scenarios the practical difference in memory consumption between a cell with a value and an empty fed cell is rather insignificant I'd say.

Update: just checked and if }StatsByCube is anything to go by then the average size of a populated data cell in one of my bigger (and quite well optimised) cubes is 33 bytes while the average size of an empty fed cell is 25 bytes. This tends to vary considerably, but for some other cubes I took as examples the results were 27B/19B, 92B/34B (this cube has strings too, so the average cell size is bigger). I would say that it's quite a bit (ha!) more than the advertised 1 bit.