Questions about performance: tactical missiles

0.5ms - 1.0ms for 25 UEF cruisers

What does that mean though? Is that 1ms over a 30min game or is that 1ms per tick? Per second?

That is per tick - apologies

To clarify further: there is 100 ms / tick to run the game at +0.

It would be pretty cool if cruisers could pick low or high arcs for missiles. Low arc: Missile flies up for a second then turns straight to target. High arc: Missile calculates turn rate on launch needed to follow semicircular trajectory.

That is for the balance team to decide - I'm just here to make things faster .

So if I understood you correctly we gain about a 1% speed improvement (1ms/100ms) in reasonable sized mid to lategame navy fights/sieges.

It's not huuge, but considering those are the situations where speed improvements matter the most it certainly is significant.

I'd say thats very much an improvement worth implementing.

Small balance note: Besides the TMDs there are also some maps that might be effected by different TML arcs. Previous save spots might be become hittable if the arc changes enough.
E.g. many spots on the setons islands are quite sensitive to the exact missile height and flight path

I would disagree. 1% sounds pretty weak to me. Remember this means if you can make the computation completely instantaneous you will gain 1% performance. So in reality you will probably be able to gain somewhere around 0.5%. Surely there are higher priority performance issues?

@Askaholic It is a bucket of water - every drop counts. If we find 10 of these type of performance gains (ambient sound is another) then we have 5ms - 10ms additional time in a tick. I'm probably not going to take on this issue myself as it is not that hard to do. But it would be a nice beginners issue for someone who has not touched the code yet, is not able to analyze the code himself yet but does want to contribute.

@cheeseberry said in Questions about performance: tactical missiles:

So if I understood you correctly we gain about a 1% speed improvement (1ms/100ms) in reasonable sized mid to lategame navy fights/sieges.

It's a 1% speed improvement if your computer is just barely able to process all of the information (it takes 100ms to process the next tick's info)

If your computer is fast enough to process everything in 90ms, it's a 0% improvement

If there's an air fight and it takes 400ms to process all the info, this wouldn't give 1% performance improvement. Saving 1 ms would be 0.25% improvement.

Since it's normal for seton's to slow to -1 or even -2 if weak PCs are involved, even outside of air fights, saving 1ms per tick would end up saving 1 second every 1000 ticks (100 seconds) so ROUGHLY it could save 1 second every 2 minutes. If my math is right, for a 30-minute game, it would save about 15 seconds, or for a 60-minute game it could save less than 1 minute of real time. But that's assuming you constantly have 25 cruisers out. So really it would only save about 30 seconds of real time 1 out of every 10 games.

Not a bad thing, but definitely not worth "breaking" the balance. (Of course it remains to be seen whether such a change would even be a bad thing for the balance.)

Small balance note: Besides the TMDs there are also some maps that might be effected by different TML arcs. Previous save spots might be become hittable if the arc changes enough.
E.g. many spots on the setons islands are quite sensitive to the exact missile height and flight path

Good point. Unironically: we need to make sure this wouldn't break Astro Craters.

It's not MY map, but it's a very important map to the community just based on the amount it gets played.

I think also those people (craters folk) don't keep up with the balance patches so they will be surprised when they make cruisers and it just doesn't work.

@askaholic said in Questions about performance: tactical missiles:

I would disagree. 1% sounds pretty weak to me. Remember this means if you can make the computation completely instantaneous you will gain 1% performance. So in reality you will probably be able to gain somewhere around 0.5%. Surely there are higher priority performance issues?

Certainly cant be picky with performance gains, like @Jip said every bucket of water counts towards better performance, plus like Jip & Sprouto said it's not one big change that fixes performances its hundreds of changes like THIS, that fix the performance.

Yes but hundreds of changes that each break a little part of the game (like the ability of cruisers to shoot over the mountains in Astro Craters) would add up to a lot of damage to the quality of the game.

As long as it doesn't impact balance too much - haven't heard anyone in this thread have anything solid on what practical balance impacts it will have as opposed to kind of vague possibilities, then I think we should do it. I don't like the idea that we should ignore it just because it's a small improvement especially since @Jip is saying it's an easy change. A good number of small improvements leads to a much bigger and more noticeable overall improvement. Granted if this wasn't an easy change then it might not be worth it over more impactful changes, it sounds like the only complexity is that it might impact balance.

Yes but hundreds of changes that each break a little part of the game (like the ability of cruisers to shoot over the mountains in Astro Craters) would add up to a lot of damage to the quality of the game.

The whole point is that I'm not breaking the balance - it just needs to be re-balanced with new parameters. As I mentioned when I made the images, they're a draft. Just an initial test to see if it is possible. Give someone another hour or two and they'll be roughly identical.

The thing about performance optimization is it’s extremely weird, counter intuitive, and will almost certainly be a disaster if you don’t collect adequate profiling data at every step of the way. One optimization can easily gain you more performance than hundreds of other ones combined if you prioritize correctly. If you just start optimizing stuff arbitrarily because a tingling sensation in your tummy tells you it’s a good idea then you’re probably gonna end up wasting a lot of time and see no benefit (but you might end up breaking the game in the process). IMO what you want to do is gather a bunch of metrics on different possible optimizations and then decide which ones to go with (I think this is what Jip is doing in his main thread). So really, we should look at this change in the context of all the other proposed changes, and my guess is we’ll probably find a lot of other stuff that is more beneficial and less dangerous.

@askaholic said in Questions about performance: tactical missiles:

The thing about performance optimization is it’s extremely weird, counter intuitive, and will almost certainly be a disaster if you don’t collect adequate profiling data at every step of the way. One optimization can easily gain you more performance than hundreds of other ones combined if you prioritize correctly. If you just start optimizing stuff arbitrarily because a tingling sensation in your tummy tells you it’s a good idea then you’re probably gonna end up wasting a lot of time and see no benefit (but you might end up breaking the game in the process). IMO what you want to do is gather a bunch of metrics on different possible optimizations and then decide which ones to go with (I think this is what Jip is doing in his main thread). So really, we should look at this change in the context of all the other proposed changes, and my guess is we’ll probably find a lot of other stuff that is more beneficial and less dangerous.

I feel like you are looking for the miracle change in the core which does not exist, it is a hundred changes that will improve the performance my guy, its not a magic bullet. You'll have to optimize units anyhow you cant dodge that, and THIS is a main issue. Yes there are obvious optimizations that make a difference but nothing is a huge magic bullet to performance.
I stress that with importance that there is in-fact no magic bullet to solving performance, and combat & balance related things will have to undergo the telescope just like everything else.

@Askaholic

The thing about performance optimization is it’s extremely weird, counter intuitive, and will almost certainly be a disaster if you don’t collect adequate profiling data at every step of the way.

I've written a profiler that counts how often functions get called. You can find it here:

• https://gitlab.com/supreme-commander-forged-alliance/other/profiler

Counting the time of functions is too unreliably. Even the benchmarks have a 10% - 20% variance even though they perform the exact same code each time. Let alone that the time does not include the garbage collector - and that is exactly the beast you'd want to profile with regard to time.

A other reasons why it is hard to use time instead of just counters:

• Threading
• Waiting
• Crashing

And a screenshot or two:

Which is the reason why there is another topic about ambient sounds.

Which is the reason of this PR: https://github.com/FAForever/fa/pull/3337

If you just start optimizing stuff arbitrarily because a tingling sensation in your tummy tells you it’s a good idea then you’re probably gonna end up wasting a lot of time and see no benefit (but you might end up breaking the game in the process).

I've written dozens of benchmarks to make sure everything I do is actually more performant. You can find them here:

• In repository: https://github.com/FAForever/fa/tree/deploy/fafdevelop/lua/benchmarking/benchmarks
• In profiler (that can run them): https://gitlab.com/supreme-commander-forged-alliance/other/profiler/-/tree/main/mods/profiler/modules/benchmarking/benchmarks

I'm not going in blind here.

IMO what you want to do is gather a bunch of metrics on different possible optimizations and then decide which ones to go with (I think this is what Jip is doing in his main thread).

At this point it is just me performing this type of work. If there would be 3 - 6 people with the right experience working on this then I'd agree with you. But it is just me for now. If I'd take that approach it would take me weeks of analyzing every bit of code and make a proper analysis while meanwhile no work gets done.

So really, we should look at this change in the context of all the other proposed changes, and my guess is we’ll probably find a lot of other stuff that is more beneficial and less dangerous.

I don't agree. I'm trying to find issues that new contributors can pick up easily from various perspectives:

• (1) To have no need to analyze / find something themselves.
• (2) To have to communicate with the other teams, in this case the balance team.
• (3) To have a stepping stone to larger PRs that will benefit way more than this one ever will.

To elaborate:
(1) The FA repository is daunting: there is no test suite of any kind. It is not complete (a lot of the base game files are still in the installation folder). It is hard to navigate at times because of that. And I can not expect people to have the knowledge to understand and find hot spots reliably. Let alone test their code reliably. This issue would be a perfect candidate: just wait for the attack cycle and test again.

(2) I am hoping to attract new contributors at some point that have no history in FAF. At first, it may be daunting to ask the balance team a question because you don't want to sound silly. Or it may be scary to ask for help because you do not want to be perceived as incompetent. This issue would force the contributor to cross that bridge, get to know people a bit better.

(3) I have a personal branch where I did the majority of the projectile files through dangerous regular expressions. See also this branch: https://github.com/Garanas/fa/tree/optimize-effects and see the changes in this PR, or the follow up PRs that again touch dozens of files.

I've described the results of those optimizations (with the units that show the original behavior, correct) in this post where 400 Zthuee all firing continuously were about 30% - 40% cheaper on the sim and I personally experienced less stuttering when comparing it to the standard branch. This would generalize over all projectiles - meaning a large battle would take up a significant smaller portion of the sim and there would be less stutters.

I can't ask a new contributor to start working on this - it is hard to test and hard to get right and the scope is gigantic. But I can ask a new contributor to start on a controlled issue, exactly the one that I am describing in this topic.

Marlo is currently working on a benchmark / test map that should help with testing large changes like these more reliably. Up to that point, performing any major non-isolatable refactoring of the base code is essentially a no-go.

less dangerous

This whole topic is here to discuss the changes and have a careful approach to something that we're all used to see in some way or fashion. That is why there is a topic about ambient sounds (that doesn't receive a lot of attention). And another about the cybran build bots (which was on fire).

I'm not trying to break the game - I'm trying to fix it. And this will require changes that will always show up in some form of another. They'll always be dangerous and potentially game breaking. And I'll always discuss them, exactly as I am doing here.

And as @Azraeel is saying: there is no magic bullet. There are a lot of small 'gotchas' that we can do. And these will just take up hours and hours of careful work over dozens if not hundreds of files. As an example you can view the benchmarks, or read about it here from legit sources:

• http://www.lua.org/gems/sample.pdf
• https://overbyte.com.au/index.php/overbyte-blog/entry/vessel-lua-optimization-and-memory-usage

Especially the latter is quite interesting as it talks about memory usage. One topic that the FA repository has been neglecting from day 1 and have been making quite a bit worse over the years. Understand me right: I'm not blaming anyone. But it is a fact - and that causes stutters that annoy the f out of me when I play the game.

Fixing that will be dangerous too. And I'll do it regardless. And I hope to start a team with people that want to join me on this journey.

With all of that said: please people, I'm not here to break (y)our game. I'm trying to fix it - discuss the changes in topics like these and lets fix it together.

You're doing awesome work Jip, thank you for it. Unfortunately it is the internet and in particular, gaming. There's always gonna be people who get worked up over any kind of change to "their" game whether it's for the best or not.

I'd love to start contributing, but I have too much on my plate right now as it is and I don't even have experience in the languages FAF uses, like LUA. But it'll definitely be on my mind to try at some point.

@snagglefox

I think you're drawing a conclusion too fast. The points Askaholic makes are very accurate. My post only describes the vision I have for an performance issue like this one.

I'd love to start contributing, but I have too much on my plate right now as it is and I don't even have experience in the languages FAF uses, like LUA. But it'll definitely be on my mind to try at some point.

I understand - luckily there are more ways to contribute. Just playing the develop branch and reporting back is part of that and highly appreciated.

I’m not sure why you all are putting so many words in my mouth. I’m not talking about magic bullets or people trying to break the game. I’m talking about making intelligent data driven decisions with a consideration of the system as a whole and not just one piece at a time.

What I think you should do is make a big table with all of the proposed changes, their possible gains and the drawbacks of doing them. Then they can be ranked and prioritized and you can knock out the low hanging fruit before even worrying about stuff that could potentially break the balance.

@askaholic said in Questions about performance: tactical missiles:

I’m not sure why you all are putting so many words in my mouth. I’m not talking about magic bullets or people trying to break the game. I’m talking about making intelligent data driven decisions with a consideration of the system as a whole and not just one piece at a time.

What I think you should do is make a big table with all of the proposed changes, their possible gains and the drawbacks of doing them. Then they can be ranked and prioritized and you can knock out the low hanging fruit before even worrying about stuff that could potentially break the balance.

That kind of stuff requires a team really. As it is, Jip made some tools to help him find some performance issues and brings them to our attention to discuss and for him or others to fix. To do it your way with just him or even a couple helpers would take forever to discover most or all things fixable and study their performance drawbacks and possible fixes.

No it doesn’t. Jip already has written a bunch of benchmarks (which he linked above) and in each of these threads he’s posted some timing information. Just compile this data into a single table and you will already be eliminating so much guesswork. It’s a simple organizational thing that will help you gain a lot more insight out of the data that you’ve already collected by looking at the system as a whole rather that just the individual pieces and then forgetting about them.