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?
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.
Rust's number types have functions like "wrapping_add" or "overflowing_add", which do not panic when overflowing and instead explicitly wrap around or return a result that must be checked.
You can easily write code that does not contain any possible panic points, if you want.
It's a shellscript that they encrypted. They decrypt it and feed the decrypted output immediately into the shell, to be sourced.
That encrypted secrets file could contain any shellscript, so the aliases are stored in there, together with the API-Keys and passwords.