TM1 Forum

Hi all,

I have been receiving conflicting views on whether using ViewConstruct with MTQ enabled in a TI will speed up the processing of a TI when the view is acting as a datasource.

The following link seems to imply that:
https://www-01.ibm.com/support/docview. ... wg21960495

I also searched the forum and a post by kangkc that he tried the above when MTQ was first introduced and found that it has no impact of the processing time when the TI processes script in Data tab. Unfortunately, there is no further update of his testing.

The idea of using ViewConstruct together with MTQ in Prolog is so that when the main TI starts the script in Data tab,the view is already cached earlier. And ViewConstruct will complete faster in Prolog due to MTQ. So the assumption is that script in Data tab will use cached Stargate view instead of querying cell by cell on demand.

Questions:
1. It seems more info that I came across state to call ViewConstruct through a sub-TI in the Prolog of the main TI. How is this better that simply directly calling ViewConstruct in the Prolog after the temp view and subs have been defined as per usual practice for a TI that uses view as source?

2. Does TI leverage on Stargate view/cached view in Data tab when a view is its datasource? If true, then it makes sense to add ViewConstruct in Prolog. Even in the absence of ViewConstruct, assuming a user had earlier made a query on the similar area in the cube, TI should benefit from this action since the view is cached.

We assume VMM has been set to a suitable value to cache the view.

Look forward to your reply!

Hi,

I might be wrong on this as it is a while and a few fix packs since I've done any detailed testing of this sort of thing, but I think...

MTQ, VMM and VMT only applies to stargate caches. TI processes do not use stargate caches for their data source, so there won't be much improvement from pre-caching the consolidations as a stargate before running the TI process.

There seems to be some emperical evidence that suggests that running a ViewConstruct with MTQ is faster than running a ViewConstruct on the same view without MTQ. But as MTQ only really applies to consolidations, not pure calculations, the amount of performance to be gained is probably more related to the number of rules which reference other consolidated cells further down the calculation chain. We have had situations where improvements of up to 3 times have been observed in complex rule driven models. Somehow MTQ seems to result in a faster population of the calculation (non stargate) cache, even though the calculations and caching of calculations is still single threaded (I think I recall hearing this from IBM).

I'm not sure why the ViewConstruct has to be in a sub process of the prolog tab, but I would assume it is to do with the way TM1 commits calculations to the calculation cache. My guess is that it does this at the end of the TI process, therefore if the ViewConstruct is run in the prolog of the current TI, not a sub-TI, the cached data hasn't been committed and therefore cannot be used by the current TI. This is basically speculation on my part!

It would be interesting to know from anyone with detailed knowledge on the inner workings of TM1 if any of this is correct!

Have you seen the new native support for MTQ as a view datasource added in 10.2.2 FP6?

http://www-01.ibm.com/support/docview.w ... wg27048366

This should completely leverage stargates for the calculation and consumption of the view.