You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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.
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.
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).
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
The text was updated successfully, but these errors were encountered: