Skip to content

Conversation

@BumblingCoder
Copy link
Contributor

This commit partially addresses the poor performance while playing the Skiessi-RandomProjectNumber demo song. This is basically only an issue because of issue #3865, but decreasing the number of allocations is probably good regardless of allocator performance.

BumblingCoder and others added 5 commits October 10, 2017 02:11
Allocating all six oscillators separately is inefficient. It is much more efficient to allocate all of them as a single block.
Allocating all six oscillators separately is inefficient. It is much more efficient to allocate all of them as a single block.
Allocating each oscillator separately was degrading performance when using the Organic instrument.
@BumblingCoder
Copy link
Contributor Author

The Organic instrument has the same issue with excessive allocations as the TripleOsc instrument did. I'm adding it to this pull request with the same changes.

oscs_r[i + 1] );
new (&oscs_l[i]) Oscillator(
&m_osc[i]->m_waveShapeModel,
&m_osc[i]->m_modulationAlgoModel,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You have unnecessary indentation here

@tresf
Copy link
Member

tresf commented Nov 15, 2017

@softrabbit or @gi0e5b06 (or someone else) can you please review this?

Copy link
Member

@lukas-w lukas-w left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a couple of suggestions. Generally speaking, this PR adds yet another quirky, slightly obscure way of manual memory management, but I can't think of a better way to do this, so I'd still say we should merge this.

I'd suggest leaving some comments explaining what's done here, at least in deleteNotePluginData. It's not obvious that delete oscLeft deletes the right oscillators too.

class EXPORT Oscillator
{
MM_OPERATORS
void* operator new( std::size_t, void* p )
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this override needed? Isn't this the default implementation?

{
Oscillator * oscs_l[m_numOscillators];
Oscillator * oscs_r[m_numOscillators];
Oscillator * oscs_all = MM_ALLOC( Oscillator, m_numOscillators*2 );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seeing that Oscillator has overloaded new operators through the MM_OPERATORS macro, we should be able to replace this with

Oscillator* oscs_all = new Oscillator[m_numOscillators * 2]

Oscillator * oscs_r[m_numOscillators];
Oscillator * oscs_all = MM_ALLOC( Oscillator, m_numOscillators*2 );
Oscillator * oscs_l = oscs_all;
Oscillator * oscs_r = oscs_all + m_numOscillators;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this alternative is clearer to readers, but I'll leave it up to you

Oscillator * oscs_l = & oscs_all[0];
Oscillator * oscs_r = & oscs_all[m_numOscillators];

static_cast<oscPtr *>( _n->m_pluginData )->oscLeft = oscs_l[0];
static_cast<oscPtr *>( _n->m_pluginData )->oscRight = oscs_r[0];
static_cast<oscPtr *>( _n->m_pluginData )->oscLeft = &oscs_l[0];
static_cast<oscPtr *>( _n->m_pluginData )->oscRight = &oscs_r[0];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

&oscs_l[0] and &oscs_r[0] can be written as oscs_l and oscs_r respectively.

delete static_cast<Oscillator *>( static_cast<oscPtr *>(
_n->m_pluginData )->oscRight );

MM_FREE( static_cast<oscPtr *>(_n->m_pluginData )->oscLeft);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In analogy to the allocation, this should be written as

delete[] static_cast<oscPtr *>(_n->m_pluginData )->oscLeft

Using MM_FREE won't call the object's destructors.


void TripleOscillator::playNote( NotePlayHandle * _n,
sampleFrame * _working_buffer )
{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comments apply to TripleOscillator.cpp.

@lukas-w
Copy link
Member

lukas-w commented Jan 7, 2018

Closing as there's been no reaction to the review and #3873 already mitigates these performance issues greatly.

@lukas-w lukas-w closed this Jan 7, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants