There are rare chances that this will… only times it may is if the call is removed/if the ResetButtonCallback string of SetCore is removed.
Though yes i do instruct you to sacrifice slight performance for security.
The statement that its faster is invalid unless the loop become infinite, and the chances of that are essentially rare…
I never said faster, I said performant. Different words, different meaning.
Sometimes SetCore is never registered, making the loop infinite.
Performant is a different word, sure, but different meaning, not so sure.
Faster in this context is very similar to performant by definition.
Performant implies lower resource usage, which is only true in certain situations.
Faster in this context means exactly the same definition.
SetCore when not registered is a bad situation either-way, if the dev intends to have the reset button disabled.
So an infinite loop is the least of their worries
The definition of fast is
performing or able to perform a particular action quickly.
but do you know of the context?
Definitions change between context.
Faster is my term of Performant when i dont want to ache my fingers typing out a longer word.
The context here is in execution speed, both performant implies faster execution speed. not that the code underneath is inherently going to be faster, but that it is bound to use less resources meaning more clock calls on the cpu, which inherently makes the code faster.
Also when is SetCore never registered, would this not be a bug?
Faster means getting something done at high speed.
Performant means to use less resources to do a task.
While performant can sometimes mean fast, fast doesn’t mean performant since I may make an installer that takes 1 second to complete (fast) however uses 16 GB of RAM (not performant)
I really don’t know however it was mentioned somewhere in this topic that this can sometimes happen.
That does not mean never… it means they are not registered at any given time
There was also a few rare cases in where it never register.
And context, as i state.
Performant when lower resources occur, mean more clock cycles can be used, which inheriently mean faster, in terms of the assembly/machine code ran underneath… less clock cycles consumed means faster execution speed.
Faster in my context implies a faster execution speed, which is what performant code would be doing underneath, otherwise the point of performant code is very nil.
And yes this is true and while performant code is faster, faster code is not necessarily performant since it can use a lot of resources.