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.

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

[mscorlib] Moving more of the String functions to managed code #5758

Closed
jamesqo opened this issue May 1, 2016 · 3 comments
Closed

[mscorlib] Moving more of the String functions to managed code #5758

jamesqo opened this issue May 1, 2016 · 3 comments
Labels
area-System.Runtime enhancement Product code improvement that does NOT require public API changes/additions untriaged New issue has not been triaged by the area owner
Milestone

Comments

@jamesqo
Copy link
Contributor

jamesqo commented May 1, 2016

As it stands, many 'high-level' string functions like IndexOf, LastIndexOf, Replace etc. are implemented natively when they could be written in managed code. I noticed this was done with one of the string.Replace overloads in f007485, so maybe it would be good to do this to make the code more accessible to newcomers, if they aren't familiar with how the C++ code maps to C#.

@jamesqo jamesqo changed the title Moving more of the String functions to managed code [mscorlib] Moving more of the String functions to managed code May 1, 2016
@jkotas
Copy link
Member

jkotas commented May 1, 2016

We have looked into this in the past and moved everything that could be moved without significant perf loss. Moving more depends on having pretty good managed optimizations for all coreclr architectures.

This makes sense to consider only once RyuJIT or better codegen is available for all architectures that coreclr runs on (x86, x64, arm, arm64).

BTW: The managed implementations of all string methods are available in corert repo.

@jamesqo
Copy link
Contributor Author

jamesqo commented May 1, 2016

@jkotas Ah, so that's why the implementations in the corert repo are managed; since it's compiled AOT and optimized by the C++ compiler, they get better codegen than the JIT implementation which is still a work-in-progress for some of the platforms you mention (arm, arm64). Thanks for clearing that up, makes sense now.

@msftgits msftgits transferred this issue from dotnet/coreclr Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@maryamariyan maryamariyan added the untriaged New issue has not been triaged by the area owner label Feb 26, 2020
@joperezr
Copy link
Member

joperezr commented Jul 1, 2020

Closing as from @jkotas response above there is nothing left to be done here. @jamesqo feel free to reopen if you think otherwise.

@joperezr joperezr closed this as completed Jul 1, 2020
@dotnet dotnet locked as resolved and limited conversation to collaborators Dec 31, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-System.Runtime enhancement Product code improvement that does NOT require public API changes/additions untriaged New issue has not been triaged by the area owner
Projects
None yet
Development

No branches or pull requests

6 participants
@maryamariyan @jkotas @jamesqo @msftgits @joperezr and others