FFI overhead is not to be neglected sometimes. I've seen cases where replacing a python or js lib with an in isolation much faster native Rust or C lib with bindings had the end result being a decrease in real-world performance due to it being in a hot path or loop and the overhead being more significant than the savings were. There is no substitute for real-world benchmarks.

   For example, before we had something like:
     top: *const FFISafe<WithOffset<&'a u8>>
   We can change that to:
     top: WithOffset<*const FFISafe<&'a u8>>

> PSA: if you don’t see syntax highlighting, disable the 1Password extension.

This linked to the following discussion that's been ongoing for over a week (with acknowledgement from 1password that they're looking into it but as far as can tell no ETA on the fix or explanation for why it's happening in the first place):

https://www.1password.community/discussions/developers/1pass...

I know that browser extensions are in general a pretty terrible ecosystem in terms of security, but am I off-base for thinking this is not a great look for 1password? Maybe I'm just underestimating how hard this is to solve generally, but my expectation would be that it shouldn't be that hard to keep track of which circumstances you're loading entire external scripts to manipulate the DOM and not do it accidentally in places you have no need for it.