DCR Type Datums vs External Reading Data of DCRs

Hi,

We've A.component with 5 types of "DCR type Datums".

We've B.component with 3 types of "DCR type Datums"

We've C.component with 6 types of "DCR type Datums"

When we closely watch these three components they have Same External and Same Controller, we are maintining as different components just for sake of different types of "DCR type Datums" data. So, now we decided to merge as Single Z.Component with Single new "DCR Type Datum"(Map dcr) whose content is DCR paths(child) of those above combinations and Wrote additional code in External Java to get content of child DCRs and appending to Result data. This way we have granualarity to add any DCR type path to Map dcr in future if needed.

The question is about performance....

During runtime,

when there's a component with 5 types of "DCR type Datums" input the content of DCRs to Component is taking 'x' time.

and when there's a External Java reading Map DCR and data of child DCRs and input the content to Component is taking 'y' time

x, y --- which performs better?

Find more posts tagged with

Comments

Ashish_Sangal

Hi Aneel,

TS provides "DCR-Category" and "DCR-Type" datum types. You can leverage these for your requirement. Refer SPDev PDF.

By using this, you won't require map dcr and extra processing done in java for reading these DCR's is not required and hence increased the performance.

Rick Poulin

aneelgkumar wrote:
The question is about performance....
During runtime,
when there's a component with 5 types of "DCR type Datums" input the content of DCRs to Component is taking 'x' time.
and when there's a External Java reading Map DCR and data of child DCRs and input the content to Component is taking 'y' time

x, y --- which performs better?

X will take a fixed amount of time whenever the component is actually executed (depends on your component cache setting).

Y will take (X+Z) time where Z is the additional overhead caused by firing off the External. You're still reading the same (or the same + 1) amount of DCRs. However, approach Y grants you the ability to cache the loaded DCRs in memory, so you don't have to do the I/O against the filesystem every time the component is rendered. If you build such caching, then Y could potentially average out to much much smaller than X.