[Just FYI] UnmanagedMemory tests / example

[Astn]

Looking for feedback and suggestions.

Related to : #41 and #46

I am trying to understand the correct way to interact with memory from the host side to allow a zero-copy approach to calling wasm functions on chucks of memory.

I would like to be able to stream through massive amounts of memory in the most efficient way possible.

The test I've added to demonstrate my initial approach only does a single load and import. I would like to extend this to function similar to an iterator, where I can keep pulling the next memory chuck in and analyzing it.

I totally understand if this isn't something you want merged into your library, but I'd love your feedback anyhow.

[RyanLamansky]

I can look at this more closely over the weekend, but my initial thought is that this would make more sense as an example rather than new unit tests. Marshal.Copy is, I believe, the fastest way to copy data in .NET, but you're hurt by the binary reader--memory mapping the file would let you skip that step and may perform better with large files.

[Astn]

this would make more sense as an example rather than new unit tests

Agreed. I started with tests to learn the API.

Marshal.Copy is, I believe, the fastest way to copy data in .NET, but you're hurt by the binary reader

The source I have to process from is a BinaryReader, provided by my database API. I was hoping to find a zero copy approach due to the wasm compiling to .net. I'd love to be able to have users compile to wasm and get the same performance as loading a user provided DLL. I haven't done any bechmarking, but from the required copy into wasm space it looks like the wasm -> dotnet will be slower than a native .net plugin model.

Any ideas on way to get shared memory that doesn't require my database driver to find a way to allocate insized wasm space? Problem is the database driver is 3rd party, and I'm not aware of a way to create an allocator that will be used by the runtime in the scope of interacting with the database.

[RyanLamansky]

Zero copy would require you to be able to pass a pointer to the desired receiving location in the UnmanagedMemory object used by the WASM to the database driver, which would then write directly to that location without any additional intermediate storage.
I suspect the database driver does not have this capability.
Consider, though, that the database driver probably has at least one internal copy operation to read from the I/O stream, so having to do one or two more shouldn't be too devastating to performance. Gigabit ethernet is about 120 MB per second, vs RAM which is capable of over 50 GB per second... there's room for less-than-perfect operation here without a significant effect on performance.

[Astn]

Zero copy would require you to be able to pass a pointer to the desired receiving location in the UnmanagedMemory object used by the WASM to the database driver, which would then write directly to that location without any additional intermediate storage.
I suspect the database driver does not have this capability.

I may have found a way to get that to work. 😁

One of the reasons I'm concerned about memory, is a single client request can result in 100's if not 100's of thousands of interactions with the database.

[RyanLamansky]

I'm glad you were able to find a solution--at that volume of DB activity, memory copies can indeed start to have a measurable impact.

As for this PR, how would you like to proceed?

[Astn]

If you think it has some value in becoming an example, I could move the code to the examples. Is this a good representation of the ideal approach?

[RyanLamansky]

I think it could be a good one. Simplifying it into a small C# app that compiles the WASM, loads data into its memory and runs the operation would be a nice addition to the examples.

[RyanLamansky]

Closing for clean-up purposes. Feel free to re-open if you have a chance to accommodate the suggestion.