Your English is excellent.
Previous experience allows you to develop a reliable “gut feel” for how system components generally work together. In the absence of a laboratory, and lots and lots of time and $$$ for testing, it is likely to give you an ‘acceptable’ outcome. Probably not ‘optimal’, but also very unlikely to be ‘unsatisfactory’.
You may or may not know that pretty much all of the world’s ‘Elite’ Special Forces are trained to operate within an inevitable “Fog of War”. Regardless of how much training is performed, or intelligence is gained, in advance of a mission, there will always be ‘unknowns’ that crop up when the mission is underway. The soldiers are trained to expect, accept, and adapt to the these unanticipated events or factors. Missions are never ‘perfectly’ executed. They are, however, usually ‘satisfactorily’ executed. Complete and perfect situational awareness is neither possible nor necessary for satisfactory mission completion.
You are in the same sort of boat. You have a goal, a lot of complex ‘moving parts’ (components) which are only partially understood, and the interactions between those moving parts will inevitably produce unanticipated/unexpected behaviours. Some of those behaviours will be beneficial. Some will not be. Some may seriously jeopardise your chances of reaching your goal.
Due to the very nature of those components, there is very little that you can do to actually ‘fix’ anything. You can’t ‘re-wire’ anything to correct architectural or design flaws. About the best you can do is ‘tweak settings’.
So, since there is little opportunity to ‘correct’ problems, a common strategy that folks use when building systems is to simply overengineer/overspec everything. If you accept that unknown problems will result in a 40% drop in FPS (for example), simply spec a GPU that delivers 40% more FPS than you actually want. Then if the problems do manifest you are still happy, but if the problems don’t manifest you end up really happy. Such excess provisioning can also be called a ‘buffer’.
Of course, large buffers cost a lot of money to create. If money is limited (and it usually is), you can invest time into researching components with the specific goal of better understanding how they will interact. The more you know, the fewer unknowns will remain, and the smaller your buffers need to be.
Only prior experience will tell you how good you are at understanding systems and judging/minimising buffers (‘right-sizing’ your system).
If you specced a system to get (for example) 1% lows of 75 FPS in GameX, then purchased the components and built it, take the time to benchmark the game and see how close you got to your goal. If you were close, great! If you missed by a significant margin (in either direction) spend some time working out why you got it wrong (low or high, you still got something wrong). In 3–5 years when you upgrade or build your next system you won’t make the same mistake again, you should get closer to your goal, and the size of any miss should be smaller. Rinse and repeat for the rest of your life. After 20-30 years you’ll be able to nail the process pretty consistenly.
You’re only ‘wildly guessing’ if you don’t reflect on past attempts and don’t keep researching and learning. If you reflect, research and learn then you are making ‘educated guesses’ — a completely different thing, and absolutely fine.
Control variables. That’s it. Control variables. Apply the scientific method. Lock down every variable you possibly can (e.g. eliminate the human from the equation, eliminate undocumented ‘features’ like energy saving from the equation) and then change one and only one variable. Run your tests. Record the results. If the problem persists, then restore your system back to the controlled base-line, and change the same variable by a different amount, or change a different variable. Run your tests. Record the results. Rinse. Repeat. Expect to spend hundreds/thousands of hours doing this before you get even a slight response/improvement.
Remember: 99.999…% of all the moving parts are hidden from view and beyond your control. You are, essentially, just hoping that you will stumble upon some setting that — for whatever reason — makes a positive difference.
There is no magic tool or set of tools that make diagnosis of bottlenecks possible. There are an infinite number of combinations of hardware and software and thus an infinite number of possible conflicts and thus an infinite number of possible reasons why you are experiencing that one, very specific symptom that is irking you on your unique system.
Even if you can find a way to make it go away, the same problem may not exist (and even if it does, your solution might no longer work) the moment any of your software (operating system, drivers, game code) gets updated. All bets are off, of course, the moment you change any of your hardware. You then start from scratch and do it all over again.
All-in-all optimising an existing system is, to a great extent, a massive waste of time. The Law of Diminishing Returns kicks in instantly. You will probably get 90% of all of the improvements (you are ever going to get) in the first hour of tweaking. You probably will only get another 9% in the next hour. Another 0.9% in the hour after that. Note that these are just percentage improvements, not percentages toward perfection or your goal — those are completely different. A fun way to pass time during a COVID lockdown, but hardly a productive use of your time.
Possibly the best bang-for-buck strategy? Move your graphics quality slider down by 1 notch. Takes all of 10 seconds. Gets you over 90% of the way to where you want to go. Makes the majority of ‘typical’ problems ‘go away’. Call it done and get on with life. IMHO a few extra ‘pretty pixels’ just isn’t worth the grief.