Evenimente
17 mar., 21 - 21 mar., 10
Alăturați-vă seriei de întâlniri pentru a construi soluții AI scalabile bazate pe cazuri de utilizare din lumea reală cu colegi dezvoltatori și experți.
Înregistrați-vă acumAcest browser nu mai este acceptat.
Faceți upgrade la Microsoft Edge pentru a profita de cele mai noi funcții, actualizări de securitate și asistență tehnică.
Property | Value |
---|---|
Rule ID | CA1844 |
Title | Provide memory-based overrides of async methods when subclassing 'Stream' |
Category | Performance |
Fix is breaking or non-breaking | Non-breaking |
Enabled by default in .NET 9 | As suggestion |
A type derived from Stream overrides ReadAsync(Byte[], Int32, Int32, CancellationToken) but does not override ReadAsync(Memory<Byte>, CancellationToken). Or, a type derived from Stream overrides WriteAsync(Byte[], Int32, Int32, CancellationToken) but does not override WriteAsync(ReadOnlyMemory<Byte>, CancellationToken).
The memory-based ReadAsync
and WriteAsync
methods were added to improve performance, which they accomplish in multiple ways:
ValueTask
and ValueTask<int>
instead of Task
and Task<int>
, respectively.In order to realize these performance benefits, types that derive from Stream must provide their own memory-based implementation. Otherwise, the default implementation will be forced to copy the memory into an array in order to call the array-based implementation, resulting in reduced performance. When the caller passes in a Memory<T> or ReadOnlyMemory<T> instance that's not backed by an array, performance is affected more.
The easiest way to fix violations is to rewrite your array-based implementation as a memory-based implementation, and then implement the array-based methods in terms of the memory-based methods.
It's safe to suppress a warning from this rule if any of the following situations apply:
Stream
subclass will only ever use the array-based methods.Stream
subclass has dependencies that don't support memory-based buffers.If you just want to suppress a single violation, add preprocessor directives to your source file to disable and then re-enable the rule.
#pragma warning disable CA1844
// The code that's violating the rule is on this line.
#pragma warning restore CA1844
To disable the rule for a file, folder, or project, set its severity to none
in the configuration file.
[*.{cs,vb}]
dotnet_diagnostic.CA1844.severity = none
For more information, see How to suppress code analysis warnings.
Feedback pentru .NET
.NET este un proiect open source. Selectați un link pentru a oferi feedback:
Evenimente
17 mar., 21 - 21 mar., 10
Alăturați-vă seriei de întâlniri pentru a construi soluții AI scalabile bazate pe cazuri de utilizare din lumea reală cu colegi dezvoltatori și experți.
Înregistrați-vă acum