Creating a flow controller overrides the default?

I added a custom flow controller in our DDS wrapper; the thing we expose to our users.

So on each domain participant abstraction object (1 x app) I attach and initialize a flow controller like the fixed rate one (rti::pub::FlowController::FIXED_RATE_NAME), but at 40Hz. This is ready to use but not a default.

We abstract the writer modes as an enum. So then internally when the user creates a writer qos through the wrapper, we set either:

writer_qos.policy(rti::core::policy::PublishMode::Synchronous());

Or:

writer_qos.policy(rti::core::policy::PublishMode::Asynchronous(getFlowControllerName(our_enum)));

Where the "getFlowControllerName" function, just returns the name of the flow controller, so DEFAULT_NAME, ON_DEMAND_NAME, FIXED_RATE_NAME or our custom FlowController's name. As below:

switch (cfg)
{
    case qos::writer_mode::sync:
        return {};
    case qos::writer_mode::async_fifo:
        return ::rti::pub::FlowController::DEFAULT_NAME;
    case qos::writer_mode::async_on_demand:
        return ::rti::pub::FlowController::ON_DEMAND_NAME;
    case qos::writer_mode::async_fixed_rate_1hz:
        return ::rti::pub::FlowController::FIXED_RATE_NAME;
    case qos::writer_mode::async_fixed_rate_40hz:
        return flowcontroller_40hz_name;
    default:
        throw local_error("Unknown qos::writer_mode");
        break;
}

We introduced the change keeping all the current configurations the same, all tests passing, but after merge we have been reported slowdowns on a team using replay and a bisect shows this change is the culprit.

If I remove our own (still unused) 40Hz flow controller the slowdown goes away.

So here's the question. Does creating a flow controller, even when not using it, has an effect on the global state? Is it made the default flow controller?