Performance-related question

[Opiumtm]

Any plans to use newly introduced Span<T> for more efficient interop with native esent.dll?

https://channel9.msdn.com/Events/Connect/2017/T125

[machish]

Did you have any specific API's to request it for?
Were you thinking of a new overload for Api.SetColumns that took Span<byte>?

(Come to think of it, there are also some APIs that could benefit from switching to IEnumerable from regular arrays.)

I'm no longer officially maintaining ManagedEsent. @michaelthorp is. :) He'd be the one to make the call on whether to increase the minimum framework version (Does Span<T> require a new framework, or just a newer compiler?).

In the past, when I made a change that required a newer framework version (was it 4.0?) that wasn't available on XP, some people complained. Now that XP is no longer getting security updates, that's not a valid reason, but there may be a similar requirement for Windows 7?

-martin

[machish]

Upon further reading of the comments:
"Yes, but Span<T> is only available as a preview. I won't ship as a stable before next year."
Drat, we'll have to wait!

[Opiumtm]

@machish Span<byte> is introduced as a "universal" structure to work not only with managed memory, but also with stack allocated or native memory. Some API members can benefit from it by avoiding unnecessary allocations as writable Span<byte> can be a part of pre-allocated memory buffer or allocated on stack, for example. So it's not only valuable for Set API members, but for Get members too as client can provide Span<byte> for the Get invoke to store column data rertieve result in a pre-allocated shared buffer or in a stack allocated buffer.

Public API is only available for byte[] to retrieve or set raw column data, so unnecessary additional memory allocations are required. It's of particular importance when complex object data is serialized and then stored in a database column as raw bytes - a common scenario for object-oriented database access.