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

performance : use direct ByteBuffers #1

Open
miraculix0815 opened this issue Oct 13, 2013 · 3 comments
Open

performance : use direct ByteBuffers #1

miraculix0815 opened this issue Oct 13, 2013 · 3 comments

Comments

@miraculix0815
Copy link

Hello,

I'm really seeing forward using your library for my unit tests. so I hope my ideas are helpful.

cite: "Alan Bateman mentioned that using direct buffers for file storage would be an excellent choice" link http://tech.puredanger.com/2008/11/10/virtual-filesystem/

If you will use ByteBuffer I propose using direct mapping for optimal performance. growing and shinking will take a lot of work, both in implementation time and execution time. If you get a byte[] determining capacity is easy.

Otherwise you have to copy the actual content and you could use a threshold before shinking and a standard growsize for growing if position reaches capacity. Similar to the size of a standard HashMap or something.

these values could later be adjustable via the environment given to FileSystemProvider.newFilesystem().

regards, jan

@SylvainJuge
Copy link
Owner

Thanks for your feedback,

I started writing this memory filesystem implementation about only ~1.5 month ago, and it is still under active development during my daily commute and spare time. There are still a lot of work to do, but I hope being able to read/write files and folders will be possible soon.

@SylvainJuge
Copy link
Owner

marked as improvement (and fixing title)

Performance is currently not yet a requirement, but I will look at it once the "core" filesystem features are operational and usable. Plus, it requires to have a realistic set of usage scenarios before doing in-depth benchmark and profiling.
However, it does not seem to take a lot of changes to use direct buffers.

@SylvainJuge
Copy link
Owner

using direct byte buffers (and byte buffers in general) requires to know their capacity in advance, thus using one byte buffer per file is not practical since it would

  • allocate more than necessary for small files
  • copy whole file when byte buffer is full and we need to append to file

However, it can still be relevant to do this at file store level, and using a single direct byte buffer for each file store.
In this case, users would require to set their FS capacity at creation time (yet only the available memory constraints the FS capacity).

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

2 participants