4 ms·
"but I’ve found that the rust-objc macros produce quite bloated code, on the order of 1.5k per method invocation" this is horror story, is dynamic ObjC even a
by slmjkdbtl 6y ago
"but I’ve found that the rust-objc macros produce quite bloated code, on the order of 1.5k per method invocation"
this is horror story, is dynamic ObjC even a valid approach over ObjC-in-C FFI? I hear it's quite slow / bloated in other languages' bindings too
- comex 6y agoEither there's something wrong with their measurement or the issue has been fixed. I tried modifying rust-objc's examples/example.rs to add 1000 method invocations, each with a unique selector: let hash123: usize = msg_send![*obj, hash123]; Comparing the built version with and without the addition, on x86-64 macOS, each message send adds, on average, 52 bytes of code (suboptimal but not terribly unreasonable) and 8 bytes to store the selector name itself (including nul terminator). That's it. Plus 113 bytes for the symbol table entry, but that goes away if you strip the binary. It's possible that the bloat comes from something else, perhaps class declarations.
- raphlinus 6y agoI think it got better, but unfortunately I never filed a bug documenting the bloat, so it's hard to track down what changed, or if I was simply wrong. My recollection is that most of the bloat was a per-invocation copy of the panic code, including formatting of the error message. Class declarations are still heavy, cargo-bloat on the current druid-shell library is showing about 900 bytes per add_method, which can add up but is unlikely to be a major source of bloat.