Forum Discussion
Solved
Change data buffer based on time
Hello,
The client has a calculation for the planning process where I used the prior period values in the calculation for current month values. Here is the data buffer I created:
Dim OpCostsDataBu...
- Don't create a new blank buffer, that's a waste of time. Just have "Dim OpCostsDataBuffer As DataBuffer = Nothing".
- Don't do constant-value calculations (" / 3 ") if you can avoid them - try leveraging the View dimension instead, which has built-in averages calculated as fast as they can be. If you add "V#MonthAvg" to your buffer definition, you should get the right numbers.
- If you really have to do calculations with constant numbers, do them inside the GetDataBufferUsingFormula clause. Yes, math with buffers also works, but there might be performance differences. GDBUF supports everything that you can have on the right side of "=" in Calculate, so you can do operations and so on.
- You don't show us how POVPERIODNUM is defined, there might be some slowdown due to a "bad" method used there (unlikely, but you never know).
- When benchmarking, always run the rule at least twice - discard times from the first run, since it's clearing up numbers from previous runs so it might not be reflective of the new rule.
Some of the slowdown is likely inevitable, for the simple reason that data is stored as YTD; so when you look at quarters, you're doing more work just to sum things up. Following the advice above should help you minimize the extra time, but it will likely never be as fast as it was before. You'll have to find gains elsewhere (e.g. executing only on specific Consolidation members, etc).
JackLacava
OneStream Employee
OneStream Employee- Don't create a new blank buffer, that's a waste of time. Just have "Dim OpCostsDataBuffer As DataBuffer = Nothing".
- Don't do constant-value calculations (" / 3 ") if you can avoid them - try leveraging the View dimension instead, which has built-in averages calculated as fast as they can be. If you add "V#MonthAvg" to your buffer definition, you should get the right numbers.
- If you really have to do calculations with constant numbers, do them inside the GetDataBufferUsingFormula clause. Yes, math with buffers also works, but there might be performance differences. GDBUF supports everything that you can have on the right side of "=" in Calculate, so you can do operations and so on.
- You don't show us how POVPERIODNUM is defined, there might be some slowdown due to a "bad" method used there (unlikely, but you never know).
- When benchmarking, always run the rule at least twice - discard times from the first run, since it's clearing up numbers from previous runs so it might not be reflective of the new rule.
Some of the slowdown is likely inevitable, for the simple reason that data is stored as YTD; so when you look at quarters, you're doing more work just to sum things up. Following the advice above should help you minimize the extra time, but it will likely never be as fast as it was before. You'll have to find gains elsewhere (e.g. executing only on specific Consolidation members, etc).
Hello,
I tried to replace the /3 and put it inside the GetDataBufferUsingFormula, but got an error. This is how I placed it:
OpCostsDataBuffer = api.Data.GetDataBufferUsingFormula("FilterMembers(RemoveZeros(F#Top:O#Top:T#" & Year1 & "Q4" &":I#Top:U5#None:U6#None:U7#Top:U8#Top),A#Op_Costs.Base,U1#Top.Base, U2#Top.Base)"/3)
This is the error: Conversion from string ":I#Top:U5#None:U6#None:U7#Top:U8" to type 'Double' is not valid. Input string was not in a correct format.
I am having 'restrictions' placed for entity, consolidation members, but having this additional logic created, it impacted the overall times.
Thank you!
After I put it
- JackLacava
you have to put the " / 3" outside the parentheses, i.e. ....U8#Top),A#Op_Costs.Base,U1#Top.Base, U2#Top.Base) / 3"
I'd still use V#MonthAvg instead, though.
I tried to test the V#QuarterAvg, but it does not get the Average when picking T#2024Q4 for example, it puts the average on Q4 periods (M10, M11 and M12), but T#2024Q4:V#QuarterAvg retrieved the total amount:
I needed to see the 208K put on T#2024Q4:V#QuarterAvg to replace the "/3" in the BR.
Also, the POVPERIODNUM is defined like this:
Dim POVPERIOID As Integer = api.Pov.Time.MemberId
Dim POVPERIODNUM As Integer = api.Time.GetPeriodNumFromId(POVPERIOID)- JackLacava
That's not bad but, if you don't need that number later, you can try this instead:
if api.time.IsFirstPeriodInYear() then ' ... etc etc End ifThat avoids allocating variables. Don't expect massive speedups, but any little helps...
