StringRefZ does not improve performance. Non-local symbols always have eagerly
computed lengths. Most local symbols's lengths will be updated in either:
- shouldKeepInSymtab
- SymbolTableBaseSection::addSymbol
Its benefit is offseted by strlen in every call site (sums to 5KiB code in a release
x86-64 build), so using StringRefZ may be slower.
In a -s link (uncommon) there is minor speedup, like ~0.3% for clang and chrome.
it looks like in both cases this code tries to "unpack" a StringRef into nameData and nameSize
(here and inside setName) - maybe just store StringRef itself ?