TM1 Forum

Hi All,
we've had problem with time taking server to start, most time consumed by processing feeders in one cube. Colleague updated most rules in the cube in this fashion:
-> and the start-up time got to almost half. Fiscal_year is a dimension with elements 2000 to 2030. But there are data ONLY for 2020,2021,2022, so no more feeders are actually set compared to previous state. I would never expect this, but in retrospect can make sense. Has anyone encountered this? Should all feeders (in large cubes) be written as specifically as possible even though nothing is fed because of 0 values? I'm confused.

Thanks for opinions!

Hi,

Your "zero" years can be overfed by a feeder like and feed further other zero cells.

And seriously, this "=>['item':'total_cost'];" feeder would confuse me more than your question.

Should all feeders (in large cubes) be written as specifically as possible even though nothing is fed because of 0 values?

I would hope not or that would incur some extra admin resource if feeders needed to be updated, for example to account for a new years data!

Why not create a rollup of relevant years and reference that on the left?
Children (Leaf elements) of that rollup are then used to feed to the right.

My question is why given cube like this (with more dimensions, large cube, just simplest slice for reference)
feeder should take longer to process than or as gtonking and MarenC (Thanks!) pointed out, better would be this, to reduce maintenance overhead: Why does it take longer given the other years 2015-2019 are empty? Hope this makes sense.

Thanks!

I think Elessar was asking the question, is 'item':'total_cost' a consolidated element?

MarenC wrote: ↑Thu Nov 03, 2022 8:46 am I think Elessar was asking the question, is 'item':'total_cost' a consolidated element?

My bad, no it is not it's just total_cost=cost_per_unit * quantity. N level elements.

If you change to feed from Quantity, instead of cost_per_unit, do you get the same problem?

Yep, it's the same.