Use unordered maps for VST3 plugin instances

The better algorithmic time complexity should help when using many (say,
hundreds) of instances of a single VST3 plugin.
This commit is contained in:
Robbert van der Helm
2021-06-11 14:48:28 +02:00
parent dec19dc12a
commit aaf3e7438c
6 changed files with 8 additions and 5 deletions
+2
View File
@@ -14,6 +14,8 @@ Versioning](https://semver.org/spec/v2.0.0.html).
completely rewritten to use both shared memory and message passing to reduce completely rewritten to use both shared memory and message passing to reduce
expensive memory copies to a minimum. With this change the DSP load overhead expensive memory copies to a minimum. With this change the DSP load overhead
during audio processing should now be about as low as it's going to get. during audio processing should now be about as low as it's going to get.
- Optimized the management of VST3 plugin instances to reduce the overhead when
using many instances of a VST3 plugin.
- Prevented some more potential unnecessary memory operations during yabridge's - Prevented some more potential unnecessary memory operations during yabridge's
communication. The underlying serialization library was recreating some communication. The underlying serialization library was recreating some
objects even when that wasn't needed, which could in theory result in memory objects even when that wasn't needed, which could in theory result in memory
+1 -1
View File
@@ -744,7 +744,7 @@ class AdHocSocketHandler {
// This works the exact same was as `active_plugins` and // This works the exact same was as `active_plugins` and
// `next_plugin_id` in `GroupBridge` // `next_plugin_id` in `GroupBridge`
std::map<size_t, Thread> active_secondary_requests{}; std::unordered_map<size_t, Thread> active_secondary_requests{};
std::atomic_size_t next_request_id{}; std::atomic_size_t next_request_id{};
std::mutex active_secondary_requests_mutex{}; std::mutex active_secondary_requests_mutex{};
accept_requests( accept_requests(
+2 -1
View File
@@ -526,7 +526,8 @@ class Vst3Sockets final : public Sockets {
* would have one dedicated thread for handling function calls to these * would have one dedicated thread for handling function calls to these
* interfaces, and then another dedicated thread just idling around. * interfaces, and then another dedicated thread just idling around.
*/ */
std::map<size_t, Vst3MessageHandler<Thread, AudioProcessorRequest>> std::unordered_map<size_t,
Vst3MessageHandler<Thread, AudioProcessorRequest>>
audio_processor_sockets; audio_processor_sockets;
std::mutex audio_processor_sockets_mutex; std::mutex audio_processor_sockets_mutex;
}; };
+1 -1
View File
@@ -529,7 +529,7 @@ class Vst3PluginProxyImpl : public Vst3PluginProxy {
/** /**
* Memoizes `IEditController::getParameterInfo()`. * Memoizes `IEditController::getParameterInfo()`.
*/ */
std::map<int32, Steinberg::Vst::ParameterInfo> parameter_info; std::unordered_map<int32, Steinberg::Vst::ParameterInfo> parameter_info;
}; };
/** /**
+1 -1
View File
@@ -204,7 +204,7 @@ class Vst3PluginBridge : PluginBridge<Vst3Sockets<std::jthread>> {
* `register_plugin_proxy()` in the constractor, and an instance is then * `register_plugin_proxy()` in the constractor, and an instance is then
* removed through a call to `unregister_plugin_proxy()` in the destructor. * removed through a call to `unregister_plugin_proxy()` in the destructor.
*/ */
std::map<size_t, std::reference_wrapper<Vst3PluginProxyImpl>> std::unordered_map<size_t, std::reference_wrapper<Vst3PluginProxyImpl>>
plugin_proxies; plugin_proxies;
private: private:
+1 -1
View File
@@ -440,7 +440,7 @@ class Vst3Bridge : public HostBridge {
* will cause all pointers to it to get dropped and the object to be cleaned * will cause all pointers to it to get dropped and the object to be cleaned
* up. * up.
*/ */
std::map<size_t, InstanceInterfaces> object_instances; std::unordered_map<size_t, InstanceInterfaces> object_instances;
std::mutex object_instances_mutex; std::mutex object_instances_mutex;
/** /**