Comment 7 for bug 1283471

Revision history for this message
Daniel Schürmann (daschuer) wrote :

We have these Hashes that will benefit:
QHash<QString, GroupStateHolder> GroupEffectProcessor::m_groupState;
QHash<QString, EffectRackPointer> EffectChainManager::m_effectRacksByGroup;
QHash<QString, EffectChainSlotPointer> PerGroupRack::m_groupToChainSlot;
QHash<ConfigKey, QWeakPointer<ControlDoublePrivate> > ControlDoublePrivate::s_qCOHash;
QHash<ConfigKey, ConfigKey> ControlDoublePrivate::s_qCOAliasHash;
QHash<ConfigKey, QString> m_descriptionsByKey;
QHash<ConfigKey, QString> m_titlesByKey;

You are right, it is in most cases the group string, that would make the difference.
We have already a hard Limit of 32 Groups inside the EngineMaster
So we can Replace the Group String by an Index of 0 .. 31 in most cases.

The pointer version has a benefit that we can convert them back to QStrings with no costs,
but we do not do this in time critical paths.

We can't get rid of the strings, since we need them in skins and midi scripts.
A QString Lookup will still require a Hash
We need String Lookup for creating ControObjectsSlaves.
Separating the Group string will be de-optimization.

Conclusion: lets introduce a Group Index!

@rryan: Can you please have a look at
https://github.com/mixxxdj/mixxx/pull/474
I includes some refactoring we can base this on.