Optimization: what are sidetable_release () and sidetable_retain ()?

Question

In my OpenGL loop, tools show 14% of my CPU time in my particle processing loop, going to objc_object::sidetable_release(bool) and objc_object:sidetable_retain() . This is important because the loop uses 100% of the processor on the iPhone 5.

I am wondering if there is a way to reduce this. I do not know what causes it, and I do not see them in so many of my methods. I think they are associated with a quick enumeration of an array of objects.

Here's what the insulting method looks like:

 -(void) updateWithTime:(ccTime)dt sceneHeightAboveHorizon:(CGFloat)yMax{ _elapsed = (_elapsed+dt) ; float farTotalWidth = EQ_SCENE_WIDTH + 2*EQ_SIZE_FAR; float farHalfWidth = farTotalWidth/2.0; for (MyParticleData *data in self.farParticleData){ //Calculate position float newX = data.pos.x + data.xVelocity * dt; if (newX > 1) newX -= 1; float newY = data.y0 + EQ_A_FAR*sin(EQ_F_FAR*_elapsed+data.phasePosition); data.pos = cc3v(newX,newY,0); //Apply new position to sprites data.sprite.position = cc3v(newX*farTotalWidth-farHalfWidth, newY*yMax, 0); data.reflectedSprite.position = cc3v(data.sprite.position.x,-data.sprite.position.y,0); //Calculate color float f = MIN(14, MAX(data.pos.x*14.0, 0)); ccColor4F newColor = cycBlendColors(self.settings.eqColumnColors[(int)f], self.settings.eqColumnColors[(int)f+1], f-(int)f); float colorAmp = MAX(0, (sin(data.frequencyColor*_elapsed+data.phaseColor)+1)/2.0); newColor = cycScaleColor(newColor,colorAmp); colorAmp *= colorAmp;//the alpha (white component) should be squared twice newColor.a *= colorAmp*colorAmp; //Apply new color to sprites data.sprite.color4F = newColor; data.reflectedSprite.color4F = cycScaleColor(newColor, self.settings.eqReflectionBrightness); } } 

Answer 1

I will try and mentally debug here -

1) You have ARC enabled

2) Some of the intermediate variables in your expressions (e.g. data.sprite, self.settings) are Objective-C objects

3) One or more of these intermediate objects are weak or atomic (or they themselves gain access to weak or atomic properties), which require additional storage / release processing upon access. - The atomic properties of IIRC will not include rigamarole tables, just a normal autoresistor, but no guarantees for that.

I would try to assign some / all of these links to a local (on the stack) variable before listing, and inside your loop to use only local links. This will have the added benefit of saving some access time from your loop.

If you know that these links will be strongly linked throughout the enumeration in 100% of cases, then you can use the __unsafe_unretained specifier for your local variables, which (basically) will prevent any attacks from ARC from appearing in this method.