Calling class_getImageName on a Swift class exposed to Objective-C is significantly slower than calling it on an Objective-C-only class, by orders of magnitude. Empirically, we've seen a difference as large as 100x—on a particular device, class_getImageName on a Swift class takes ~2ms whereas it takes ~20µs on an Obj-C-only class.
When the Swift runtime hooks class_getImageName with its own version, it calls dladdr, which takes longer because it populates the Dl_info struct with other information that gets thrown away. (The other class metadata accessor calls are fast, as they merely return pointers or do pointer tests.) <
By my own rough benchmarking, the CoreFoundation approach is still slower than calling dyld_image_path_containing_address directly, but only by a factor of about 4x in an optimized build, so it would still be a large improvement, and perhaps there are other ways to improve it further.
Are there drawbacks to doing either of these replacements, or anything I haven't considered?
The text was updated successfully, but these errors were encountered:
Thanks for the report! I suspect that we're using dladdr just because it's been that way, and this hasn't been a performance bottleneck. I think we should switch it to dyld_image_path_containing_address. This would be far from the only internal call used by the Swift runtime, and it's safe to do so since Swift is bundled in the OS.
If you feel like making a PR with this fix, I'd be happy to review it and see if we can get it in. Otherwise I'll see if I can find a moment to do it on our end.