Quantcast
Channel:
Viewing all articles
Browse latest Browse all 8

Using CnC with a large number of nodes

$
0
0

The key issue is reducing the number of types. If different steps (or tuners)only differ in a "static" value/attribute, you can reduce the number of step-collection types by parametrizing a singlestep-collection-type: Give the step an unmutable attribute to differentiate between different "types". When creating the step-collection instances just pass a step-instance instantiated with the right parameter as an argument to the constructor fo the step-collection. This removes static differences by making them runtime options. It should have no significant effect on the runtime performance. Here's a sample code snippet:

struct my_step 
{
    int my_arg;
    my_step( int a ) : my_arg( a ) {}
    int execute(...)
    { //do the work dependent on my_arg }
};

struct my_context : public CnC::context< my-context >
{
    CnC::step_collection< my_step > m_sc1;
    CnC::step_collection< my_step > m_sc2;
    my_context() 
        : m_sc1( *this, "step1", my_step( 1 ) ),
          m_sc2( *this, "step2", my_step( 2 ) )
    { // do all the graph wiring etc. }
};

This is in the new API syntax. I recommend switching to the new release (0.7).

You can do similar thing with the tuner argument to the step-collection constructor. The difference is that the optional tuner argument must persist over the lifetime of the step-collection, while the step-instance is copied when the collection is constructed.

Another trick is to embed the parameter in the tag. While this also reduces the number of collection types, it will apparently duplicate data/information in each tag. In some cases it might be easer to implement, though.

Does this help?

frank


Viewing all articles
Browse latest Browse all 8

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>