Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Note of performance improvement #110

Closed
Xuanwo opened this issue Mar 7, 2022 · 0 comments
Closed

Note of performance improvement #110

Xuanwo opened this issue Mar 7, 2022 · 0 comments

Comments

@Xuanwo
Copy link
Member

Xuanwo commented Mar 7, 2022

This note is used to track performance improvement.

Please let me know for any ideas.

Possible Ideas

  • Readiness based API
    • Requires internal buffering(?), maybe worse on sequential read.
  • Allowing creating a different hyper client for s3 instead of sharing the same one.

Not work

Self-maintained runtime

To spawn a new task on tokio runtime, we can't have reference:

fn spawn<T>(&self, future: T) -> JoinHandle<T::Output>
where
    T: Future + Send + 'static,
    T::Output: Send + 'static,
{
    match self {
        Executor::External => tokio::spawn(future),
        Executor::Global => GLOBAL_EXECUTOR.spawn(future),
        Executor::Internal() => unimplemented!(),
    }
}

So we have to take an owned buf like monoio and tokio-uring:

fn read(&self, path: &str, offset: u64, buf: Vec<u8>) -> JoinHandle<Result<(usize, Vec<u8>)>> {
    let (_, _, _) = (path, offset, buf);
    unimplemented!()
}

fn write(&self, path: &str, buf: Vec<u8>) -> JoinHandle<Result<()>> {
    let (_, _) = (path, buf);
    unimplemented!()
}

However, these API requires extra alloc and memory copy which drops 50% read performance.

Here is another try that keeps returning BoxedAsyncRead:

fn read(&self, path: &str, offset: u64, size: u64) -> JoinHandle<Result<BoxedAsyncRead>> {
    let (_, _, _) = (path, offset, size);
    unimplemented!()
}

There is no significant performance on regular benches, but we can find performance drops under parallel read benches.

@Xuanwo Xuanwo changed the title Tracking issue of performance improvement Note of performance improvement Mar 8, 2022
@apache apache locked and limited conversation to collaborators Mar 8, 2022
@Xuanwo Xuanwo converted this issue into discussion #111 Mar 8, 2022

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant