NSStringFromClass optimized: replaced String(reflecting:) with _typeName

[ChrisBenua]

NSStringFromClass optimized by replacing String(reflecting:) with _typeName

Motivation:

Optimizing NSStringFromClass.

Modifications:

I've replaced heavy String(reflecting:) call with _typeName function. It's valid because String(reflecting:) eventually calls _typeName function

Result:

NSStringFromClass will work much faster.

Testing:

Tested locally. Basically, testing is not needed because calls are equivalent and there are unit-tests in TestObjCRuntime.swift. The same change was made here: swiftlang/swift#77369

[grynspan]

Can you define "much faster"? Have you measured the performance difference? Do you have any metrics to share?

[ChrisBenua]

Can you define "much faster"? Have you measured the performance difference? Do you have any metrics to share?

Jonathan, I've answered the same question in similar PR

[jmschonfeld]

This seems like something that should be fixed within String(reflecting:) instead of _typeName - changing this everywhere isn't sustainable and _typeName is also an underscored API that projects not in the toolchain should not be using. Has there been an effort to update String(reflecting:) for all projects instead of updating call sites in every project manually?

[ChrisBenua]

This seems like something that should be fixed within String(reflecting:) instead of _typeName - changing this everywhere isn't sustainable and _typeName is also an underscored API that projects not in the toolchain should not be using. Has there been an effort to update String(reflecting:) for all projects instead of updating call sites in every project manually?

I haven’t attempted to modify String(reflecting/describing:) yet. I wonder what possible solutions there are. As for me, introducing new overloads for String(reflecting/describing:) with an argument of Any.Type should be fine.
There is another option — handle all metatypes in casting to protocols inside the Swift Runtime: if a type is a metatype, it can’t conform to any protocol, so skip all checks (iterating through all protocol conformance descriptors). In my opinion, this is overkill for most cases, despite the fact that it can cover more potential cases

[jmschonfeld]

I think we should investigate that avenue more (fix this in the stdlib/runtime instead of fixing this in every library that calls this function). Fixing this in every library isn't tenable and if this is indeed a good fix let's make it at the best spot possible. That way it doesn't leave unclear usages of underscored APIs in a variety of projects