This can be done reliably, though.
You can just do
if a == b {
...
Just that the check will be replaced at compiletime with a constant, since the borrow-checker tracks all objects lifetimes and can use that information to optimize the check away.
The objects themselves don't make it into the compiled binary, since they have no size, but all the required information about them will make it in. So you can treat them like ordinary objects and do all the usual operations on it, without wasting any memory during runtime.
In general our types won't be comparable, suppose we've got three zero size types Truth, Beauty and Strange and we make six variables a and b have type Truth, c and d are Beauty, e and f are Strange:
Out of the box a == b will not compile, for the same reason that in most languages you can't divide the string "This" by the string "That" you cannot use this operator here because it's nonsense unless somebody defines what it means.
We can define an implementation for this operator on Truth, but, it has nothing more to go on than what we already knew - remember these are zero size types so they do not have properties we could investigate, we can say they're always equal, in which case a == a is now true too, or indeed that they're never equal, in which case a == a is now false - they don't have identity, we can't tell them apart.
We're allowed to write implementations for comparisons to other types, so we could say you can compare a Truth to a Beauty, and a Beauty to a Strange, but you can't compare a Strange to a Truth for example, so then a == c would compile and so would c == f but a == f would not compile.
Yes, if the types are known none of this results in any actual operations at runtime because it'll get optimised out.
In my experience, it is pretty rare to run much actual work on a microcontroller.
Testing at effectively idle represents most of my usecases.
For the times where there is a background load: RTIC has task priorities and pre-emption, so you can run your compute-intensive task with a lower priority and react to interrupts in a timely manner.
My work laptop currently has 96GB of RAM. 32 of it is allocated to the graphics portion of the APU. I have 128GB (2x) of SWAP allocated, since I sometimes do big FPGA Synthesizations, which take up 50GB of RAM on its own. Add another two IDEs and a browser, and my 64GB or remaining RAM is full.
Weird. My android phone is 3+ years old and was not a flagship when I got it. It had a little problem with stuttering on more complex examples. It sounded like it was running out of things that can play at the same time, but scrolling was still smooth. It didn't feel like it was pinning my phone's cpu.
On my laptop, it didn't break a sweat with firefox and pipewire.
Are you sure it's not a config issue?
I can't tell, things like BespokeSynth are running ok with alsa or jack. I got the rt kernel, made a few things to audio priority, fiddled with governors, but no luck. Let's say that it happens quite quickly with the Stitch Angel fast trance example "the key needs to be G" supersaw synth.
Have you thought about just not making the variable global and instead adding it as a parameter to the functions that actually need it?
You can also create a struct, put your "global" variable inside it and then put all the functions that need the variable into an Impl block of that struct.
If you then add the parameter `&self` to these functions, you can access the "global"variable any time via `self.global_variable`.
If that is not enough, then you can always make an actual global variable by first wrapping it in a Mutex, to prevent simultaneous access and then wrapping that in an Arc for Atomic Reference Counting. That allows you to pass "copies" of that variable around anywhere, satisfying the borrow-checker (since the variable is now reference-counted in a thread-safe way).
If you need a lot of parallel reading, replacing the Mutex with an RwLock is a good idea, since it allows locking from multiple threads, if you want to read it in most cases.
if a == b { ...
Just that the check will be replaced at compiletime with a constant, since the borrow-checker tracks all objects lifetimes and can use that information to optimize the check away.
The objects themselves don't make it into the compiled binary, since they have no size, but all the required information about them will make it in. So you can treat them like ordinary objects and do all the usual operations on it, without wasting any memory during runtime.