Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

.NET - Potentially large memory allocation at each call #18

Closed
ArtemAvramenko opened this issue May 9, 2023 · 3 comments
Closed

.NET - Potentially large memory allocation at each call #18

ArtemAvramenko opened this issue May 9, 2023 · 3 comments

Comments

@ArtemAvramenko
Copy link

ArtemAvramenko commented May 9, 2023 •
edited
Loading

In the code there is such a thing:

private static ReadOnlySpan<byte> Bank => new byte[64436]
{
    83, 104, 99, 104, 39, 101, 117, 101, 117, 101,
    // .. 62 Kb more data
};

Probably the expectation here was that the array would be created once. But in fact it will be created every time the property is accessed, because the expression-bodied property is just syntactic sugar for get { return new ... }

To avoid potential memory problems you should replace this with:

private static ReadOnlyMemory<byte> Bank { get; } = new byte[]
{
...
@ArtemAvramenko
Copy link
Author

I'm also wondering what the reason is for not using a simple Dictionary<char, string> for mapping?

@hunterwb
Copy link
Member

hunterwb commented May 9, 2023

Due to compiler optimizations none of the arrays are allocated or even exist, the spans refer directly to static data
dotnet/csharplang#5295
dotnet/roslyn#24621
A large static dictionary causes problems
dotnet/runtime#54688

@ArtemAvramenko
Copy link
Author

Oh, I missed that news about compiler optimization, it's really confusing in its non-obviousness. Thanks for the useful information

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@hunterwb @ArtemAvramenko