Hello, I have inherited a few applications that utilize nservicebus. Something that I noticed in the configuration logic in virtually all of the endpoints what a chunk of logic performing .DisableFeature();. Many of them are in memory features, some of them arent leveraging sagas etc.
My question is, is there any performance or really any other benefit to doing this in all these endpoints?
Hi Jeremiah
Would you mind sharing some snippets of what features are disabled? I’m not entirely clear based on your description.
That would help me to hopefully give you a more concrete answer rather than “it depends” 
Regards,
Daniel
You bet!
Hi Jeremiah
Previously the InMemoryPersistence was part of NServiceBus. In newer versions of NServiceBus the InMemoryPersistence has been moved to a dedicated package called NonDurablePersistence.
By looking at the above screenshot it looks like the original authors wanted to disable all the feature that they did not plan to use. In general this can indeed have “performance” implications on startup.
For example the saga feature is enabled by default on an endpoint. As part of setting up NServiceBus during starting the saga feature will go through all types from all the assemblies scanned and look for saga types to automatically setup dependency injection and some other things for sagas. If an endpoint doesn’t need sagas disabling the saga feature can give a few milliseconds of startup boost. That type of "micro-optimization might be relevant in environments when the cold start time needs to be optimized. For example AWS Lambda or Azure Functions might benefit from such an improvement.
Disabling the timeout manager was something that could be done too if no timeouts are needed on an endpoint. That would be the case when you don’t have sagas and the transport of choice supports native delayed delivery which is the case for RabbitMQ, Azure Service Bus, Storage Queues, SQS and SQL Server (and I believe in newer version of MSMQ the support for delayed delivery has also been moved into the transport). Newer version of NServiceBus automatically deal with doing the right thing in regards to the timeout manager so this line is pretty much redundant.
When it comes to AutoSubscribe I would say this can be a deliberate design choice. AutoSubscribe means that all handlers that are discovered during the startup will be inspected for the message type being handled and then the transport will automatically subscribe to that message type. This can mean that subscriptions and “rules” are setup on the transport to make sure message types are routed to the endpoint. Some teams prefer to manually manage the transport “topology” by deploying the topology as part of their deployment scripts or use tools that we ship as part of the transport to “script” the topology. An example of such a tool is the asb-transport tool. In some cases setting the topology requires elevated permissions on the transport. By moving the topology creation outside the endpoint when the transport doesn’t support settling the topology without elevated permissions gives the additional benefit of using least-privilege.
These are some scenarios when disabling AutoSubscription makes sense.
Hope that clarifies a few things
Regards,
Daniel