Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Objective-C interop is too slow #2145

Open
kvark opened this issue Jun 12, 2018 · 6 comments
Open

Objective-C interop is too slow #2145

kvark opened this issue Jun 12, 2018 · 6 comments

Comments

@kvark
Copy link
Member

kvark commented Jun 12, 2018

I can see us spending quite a bit of time in querying the obj-c selectors on each message send.
Upstream issue - SSheldon/rust-objc#49
One possible solution (that needs to be revived, cc @mystor): https://github.com/mystor/objc_methname

@jrmuizel
Copy link
Contributor

@gankro was looking at stabilizing const string length or something like that. Hopefully, he can remind us what the current status is.

@Gankra
Copy link

Gankra commented Jun 12, 2018

#![feature(const_slice_len)]

static string: &[u8; b"hello".len()] = b"hello";

fn main() {}

compiles on nightly; we just need to push to stabilize this feature (which should be trivial?)

@vincentisambart
Copy link

For the time being, have you tried using for example lazy_static for selectors? Last time I tried it didn't seem to be much slower from having the system resolving them a launch, and way faster than resolving the selector at each call (as msg_send! does).
Something like that:

use objc::Message;

#[allow(non_upper_case_globals)]
mod selectors {
    use objc::runtime::Sel;

    lazy_static! {
        pub static ref isEqual_: Sel = Sel::register("isEqual:");
    }
}

fn is_equal(object: *mut objc::runtime::Object, compared_to: *mut objc::runtime::Object) -> bool {
{
    let ret_val: BOOL = unsafe {
        (*object)
            .send_message(*selectors::isEqual_, (compared_to,))
            .unwrap()
    };
    ret_val != 0
}

Also changing it later on to use link_section instead should be pretty straightforward.

@kvark
Copy link
Member Author

kvark commented Jun 13, 2018

@vincentisambart honestly, this is not as urgent to get in stable as it is important to just see what impact it's going to have. So while your suggestion is completely reasonable, I'm leaning towards rolling out support for it under "nightly" feature and checking out how it helps in the meantime. Those few of us who do the benchmarking could easily use the nightly, while for others it's not a blocker in any way.

Also, cc @pcwalton as requested.

@jrmuizel
Copy link
Contributor

@gankro, do you mind filing an issue about stabilizing const_slice_len?

@Gankra
Copy link

Gankra commented Jun 15, 2018

there's some issues with const fn stuff that means they're not quite ready for it; but nika wrote up a version that doesn't need it (kvark has it)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants