This question are so basic that I feel bad opening a topic for it, whish there was a chat instead, maybe I should propose that later

Anyway, here's my code:

// Called every frame
void UOpenDoor::TickComponent(float DeltaTime, ELevelTick TickType, FActorComponentTickFunction* ThisTickFunction)
{
	Super::TickComponent(DeltaTime, TickType, ThisTickFunction);

	OpenDoor(DeltaTime);
}

void UOpenDoor::OpenDoor(float DeltaTime) {

	float RotationAmmount = RotationSpeed * DeltaTime;
	if (!FMath::IsNearlyEqual(CurrentYaw, OpenYaw, RotationAmmount))
	{
		float NewYaw = CurrentYaw - RotationAmmount;
		CurrentYaw += NewYaw < -180 ? NewYaw + 360 : -RotationAmmount;
		GetOwner()->SetActorRotation(FRotator(0.f, CurrentYaw, 0.f));
	}
}

My question pertains the OpenDoor() function called every frame.

As you see I'm creating 2 floats inside of it every frame(let's assume this door keep opening forever), is this a good practice or since it happens every frame I should rather have those 2 floats as persistent private variable of my class? Between the two methods, there can be any noticeable performance difference with many assets that create 2 floats at every frame?

My second question is similar to the first, but is about the GetOwner() function called every frame. Should I rather store a Owner pointer in my class? Can this become noticeably expensive if I have many objects calling GetOwner function at every frame?

Just now, MarcusAseth said:

This question are so basic that I feel bad opening a topic for it, whish there was a chat instead, maybe I should propose that later

https://www.gamedev.net/community/chat/

Regarding the variables:

floats (and other built-in values) are trivial. Don't worry about them, unless you're creating an absolutely insane amount of stuff every frame. If you are, you're likely doing other stuff completely wrong in the first place.

Regarding GetOwner:

This could probably do with being cached. Look it up once at the start and store it.

Apart from that:

When dealing with performance, you should always be armed with a profiler. Measure, change, measure again. Additionally, worrying too much about performance when performance isn't an issue is very likely to be a waste of time. Focus on getting stuff working.

Thanks Lactose, I'll store Owner pointer then  

I'm not ready yet to measure stuff I think, no idea of what I am doing, and I would probably end up measuring the wrong things and jumping to wrong conclusions based on that. Unfortunately from time to time the "fear of bad performance ghost" (which I never met) comes back up and distract me from the currently relevant stuff

Glad there is a chat, is it a voice chat only though? I can only type

Just now, MarcusAseth said:

Thanks Lactose, I'll store Owner pointer then  

I'm not ready yet to measure stuff I think, no idea of what I am doing, and I would probably end up measuring the wrong things and jumping to wrong conclusions based on that. Unfortunately from time to time the "fear of bad performance ghost" (which I never met) comes back up and distract me from the currently relevant stuff

Glad there is a chat, is it a voice chat only though? I can only type

 

Learning to use a profile is, like learning to use a debugger, a very valuable skill. It might not be critical right now, but if you run into actual performance issues later on, I would highly recommend investing the time then.

The chat is text, using Discord.

What is the chance that the compiler makes your float global for you ?, it could be possible you dont know how its being optimized.

About the GetOwner() , indeed is better to have a pointer at initialize.

The best optimization is to perform 1 door every frame, not all doors,

you have a list, call list->opendoor()

then set the pointer in the list to the next door, ready to check in the next frame.

You should do this for everything where possible btw, spread it out over more frames if timing is not crucial.

That's interesting, though I have some doubts:

let's say someone PC is running the game at 30 fps and I have 100 doors in my list, let's say the pointer is at the first door of the list and the player is in front of the last door on the list, now they have to stand in front of this door little more than 3 seconds before something happens, right? And that would be considered a bug by the player

Oh well, I bet is the reason you said " if timing is not crucial"

No, you have only the doors of the current zone in the list.

For every zone you have lists.

Keep in mind this sort of logic is often trickier to write than the straight-forward alternative. And even correctly implemented, it might not have any noticable effect on your game's performance -- there might be other problems dwarfing whatever gain you can get from this setup.

It might very well be a good option in a lot cases (it's a fairly common technique) where it's applicable, but when it comes to anything relating to performance, the best option is always to profile and go from there. Measure, change, measure & compare. Repeat until good enough.

1 minute ago, the incredible smoker said:

No, you have only the doors of the current zone in the list.

It's easy to imagine a scenario where the design calls for 100 doors on-screen and wanting to open them all at once, in perfect sync. Or a scenario where timing of two different doors must be the same.

Your suggestion isn't a solution for every single case -- like you said, only if timing is not crucial. Sometimes, timing is crucial.

Going on a bit, since this is For Beginners and you write that you aren't really sure what to do, the answer is that you shouldn't be worried about performance yet.

Anything you write as an individual is unlikely to tax your computer.  The only real exception to that is things that are breathtakingly wrong from a programming perspective. In that case the problem creates a learning exercise for you.  If you encounter those, people on the forum can usually help you spot them easily. Also, they'll usually be the things you've changed most recently.

Your computer is able to perform many hundred million operations every frame.  Consider the biggest video games your computer can handle, then realize that it can handle all of that work.  Creating a variable is approximately nothing.  Sorting hundreds of game objects in the world based on distance is approximately nothing. 

After you gain experience, when you understand more about programming and know several variations and assorted algorithms to accomplish a task, and when you're in a position to understand the tradeoffs between those algorithms, that's when you'll be ready to start having good conversations about performance.

On 27/08/2017 at 0:09 AM, MarcusAseth said:

My second question is similar to the first, but is about the GetOwner() function called every frame. Should I rather store a Owner pointer in my class?

Do you have the source code there?

If you do, you can see that GetOwner() is a FORCEINLINE function which returns a copy of a cached 'OwnerPrivate' pointer. It's already pretty much as fast as it can be, so there's no need to cache it yourself.