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

Performance: Direct mapped library and callbacks #33

Open
tass01024 opened this Issue Dec 8, 2013 · 2 comments

Comments

Projects
None yet
3 participants
@tass01024

tass01024 commented Dec 8, 2013

Thanks for the good work!

Would it not be a performance boost to use directly mapped library (LibFuse) and FileSystem callbacks (Options: Native.CB_OPTION_DIRECT) to boost performance of the calls?

By using JNA's: Native.register instead of loadLibrary and using the Native.CB_OPTION_DIRECT

It would ofcause require some refactoring of the code.

/rasmus

@EtiennePerot

This comment has been minimized.

Show comment
Hide comment
@EtiennePerot

EtiennePerot Dec 8, 2013

Owner

I'm not entirely clear on what this would achieve besides shorter stacks, which I don't really think are a bottleneck. Feel free to try it though.

Owner

EtiennePerot commented Dec 8, 2013

I'm not entirely clear on what this would achieve besides shorter stacks, which I don't really think are a bottleneck. Feel free to try it though.

@rossjudson

This comment has been minimized.

Show comment
Hide comment
@rossjudson

rossjudson May 23, 2014

You mention that allocating direct byte buffers is a significant bottleneck, and those are known to be slow.

It's possible that can be mitigated by changing

  final ByteBuffer buf = buffer.getByteBuffer(0, bufSize);
  final FileInfoWrapper wrapper = new FileInfoWrapper(path, info);
  final int result = read(path, buf, bufSize, readOffset, wrapper);

into something more like

  final byte [] buf = buffer.getByteArray(0, bufSize);
  final FileInfoWrapper wrapper = new FileInfoWrapper(path, info);
  final int result = read(path, buf, bufSize, readOffset, wrapper);
  buffer.write(0, buf, 0, bufSize);

The JVM is pretty efficient with transient byte arrays, so it might not make sense to pools those.

rossjudson commented May 23, 2014

You mention that allocating direct byte buffers is a significant bottleneck, and those are known to be slow.

It's possible that can be mitigated by changing

  final ByteBuffer buf = buffer.getByteBuffer(0, bufSize);
  final FileInfoWrapper wrapper = new FileInfoWrapper(path, info);
  final int result = read(path, buf, bufSize, readOffset, wrapper);

into something more like

  final byte [] buf = buffer.getByteArray(0, bufSize);
  final FileInfoWrapper wrapper = new FileInfoWrapper(path, info);
  final int result = read(path, buf, bufSize, readOffset, wrapper);
  buffer.write(0, buf, 0, bufSize);

The JVM is pretty efficient with transient byte arrays, so it might not make sense to pools those.

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