Time Complexity AND Space Complexity (memory usage) are missing from Types/Methods/ExtensionMethods that are typically used for Performance Tuning

[udlose]

Describe the issue or suggestion

Please include BOTH Time Complexity and Space Complexity. Having Space Complexity is so important nowadays with performance efforts very frequently focused on reduction of memory consumption. This is extremely important for Data Types and methods/extension methods that are considered "go-to's" for performance tuning nowadays with performance efforts very frequently focused on reduction of memory consumption.

Currently, the only way to get a rough estimate is to write benchmarks using BenchmarkDotNet to try and measure memory consumption. However, this technique is:

1. time-consuming
2. results depend on how well (comprehensive) the benchmarks are written.
3. an unreasonable ask to consumers of the libraries. It is like leaving out the description of what the types/methods do and having developers write test code to see how the types/methods work to achieve their task.

Most devs aren't going to spend the time to write comprehensive benchmarks considering that writing these benchmarks is time consuming. Thus, they end up possibly selecting the wrong type or method for their use-case. For example, trivial benchmarks with a smaller data set may appear that a method scales as O(2N) whereas a more comprehensive benchmark would show that the space complexity scales much differently as the data changes.

I do understand that keeping up with documentation is a challenge as the rate that the .NET ecosystem has increased dramatically over the years. However, consider this:

• it is equally difficult to keep up with the Types/Methods/ExtensionMethods being added
• most importantly, how useful are Types/Methods/ExtensionMethods that do not contain this information to those looking to properly tune and fix performance issues.

Thank you for your consideration!

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[steveharter]

This is extremely important for Data Types and methods/extension methods that are considered "go-to's" for performance tuning nowadays with performance efforts very frequently focused on reduction of memory consumption.

I think the issue is where should the doc go, and for what.

The existing documentation consists of various categories (such as APIs and conceptual), and for specific "Data Types and methods/extension methods" the perf doc should probably go into each API link as appropriate, such in in the Remarks section. So, in general, we should just have individual issues for those since it is not likely there will be a concerted effort to overhaul all the APIs to add such content.

There are also blogs, some of which focus on performance exclusively including release-to-release changes such as this one for v9.

Thoughts @stephentoub ?

[udlose]

This is extremely important for Data Types and methods/extension methods that are considered "go-to's" for performance tuning nowadays with performance efforts very frequently focused on reduction of memory consumption.

I think the issue is where should the doc go, and for what.

The existing documentation consists of various categories (such as APIs and conceptual), and for specific "Data Types and methods/extension methods" the perf doc should probably go into each API link as appropriate, such in in the Remarks section. So, in general, we should just have individual issues for those since it is not likely there will be a concerted effort to overhaul all the APIs to add such content.

There are also blogs, some of which focus on performance exclusively including release-to-release changes such as this one for v9.

Thoughts @stephentoub ?

I don't think that developers should have to reference anything other than the Reference API Documentation - no blogs, no release notes, etc. The API Documentation at https://learn.microsoft.com/ is where I'd expect it to be found.