Closed roterdam closed 6 years ago
MMF files work on unmanaged memory blocks via "black art" of safehandles/obtaining byte*
and other activities which introduce edge checks. MMF memory access is always slower than byte[]
which is managed and bypasses those checks. See MMFMemory.cs
see: m_View.SafeMemoryMappedViewHandle.AcquirePointer(ref ptr); .....
m_View.SafeMemoryMappedViewHandle.ReleasePointer();` in https://github.com/agnicore/nfx/blob/master/src/NFX/ApplicationModel/Pile/PileImpl/MMFMemory.cs
plus it makes copies to be used by Stream etc...
now contrast that with:
https://github.com/agnicore/nfx/blob/master/src/NFX/ApplicationModel/Pile/PileImpl/LocalMemory.cs
Thank you very much. It makes sense. I've built something like NFX myself, but really for fun and I was unable to notice a difference in performance.
But I realize why NFX MMF is slower ... because it is CORRECT :) ... My version has no checks and so things like GC cleanup, checking out of bounds, etc are not there.
Great work!
Hello,
I read in your benchmarks that MMF Pile is slower than byte[] Pile. Why is this?
Is it only for cases where you'll be converting from MMF format to CLR format? For example, if you have a MMF Pile Object representing a UTF16 String and you have to convert it to CLR string it is somehow worse when using pointer math to generate a CLR string? Versus copying it from a byte[]?
I would have thought that MMF Pile vs byte[] Pile should be 100% equivalent in perf.