Skip to content

Conversation

@jstedfast
Copy link
Owner

The main advantage of this change is to make the code a bit nicer. The AsyncMimeReader code, especially, becomes a lot nicer with this change.

The other advantage is that Spans don't interfere with the GC like pinned memory buffers do, which could theoretically mean that using MimeReader is less likely to result in memory fragmentation (although not sure on the real-world consequences of the previous code in practice).

The downside is that ReadOnlySpan.IndexOf() is slower than the current implementation on .NET Framework and possibly also even .NET Core where the platform architecture does not have support for SIMD.

That's why this PR is a Work-In-Progress and not yet merged to master.

@coveralls
Copy link

coveralls commented May 4, 2025

Coverage Status

coverage: 94.812% (-0.02%) from 94.827%
when pulling 2c6ea3c on mimereader-span
into 1921c1b on master.

The main advantage of this change is to make the code a bit nicer. The
AsyncMimeReader code, especially, becomes a lot nicer with this change.

The other advantage is that Spans don't interfere with the GC like pinned
memory buffers do, which could theoretically mean that using MimeReader is
less likely to result in memory fragmentation (although not sure on the
real-world consequences of the previous code in practice).

The downside is that ReadOnlySpan<byte>.IndexOf() is *slower* than the
current implementation on .NET Framework and possibly also even .NET Core
where the platform architecture does not have support for SIMD.

That's why this PR is a Work-In-Progress and not yet merged to master.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

performance Improvements to speed or memory consumption

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants