prehashed is called quite often now:

❯ rg "::prehashed\("
libwild/src/version_script.rs
77:                self.exact.insert(UnversionedSymbolName::prehashed(exact));
98:                .contains(&UnversionedSymbolName::prehashed(demangled_name.as_bytes()))
532:        let Some(m) = script.find_match(&UnversionedSymbolName::prehashed(name.as_bytes())) else {

libwild/src/diagnostics.rs
64:            .get_unversioned(&UnversionedSymbolName::prehashed(name.as_bytes()));

libwild/src/symbol_db.rs
1119:            let name = UnversionedSymbolName::prehashed(info.name_bytes);
1231:            let name = UnversionedSymbolName::prehashed(name_bytes);
1553:        Self::from_prehashed(symbol_id, UnversionedSymbolName::prehashed(name))
1572:            name: VersionedSymbolName::prehashed(name, version),

libwild/src/symbol.rs
86:        let name = UnversionedSymbolName::prehashed(name_info.name_bytes);
88:            PreHashedSymbolName::Versioned(VersionedSymbolName::prehashed(name, version))

libwild/src/layout.rs
3173:                .get_unversioned(&UnversionedSymbolName::prehashed(
4644:            .contains(&UnversionedSymbolName::prehashed(

libwild/src/resolution.rs
627:        .get_unversioned(&UnversionedSymbolName::prehashed(name))

libwild/src/elf_writer.rs
2807:                            .version_for_symbol(&UnversionedSymbolName::prehashed(sym_def.name))

but I don't know if this is avoidable.

Might be something that can be included into refactoring as mentioned in #994.

While multiple calls for the same symbol could be bad for performance, I'd say what perhaps matters most here is whether we actually make that call most of the time. I'd assume that in the vast majority of linker usages, the list of explicit exports will be empty. So, if we can avoid calling prehashed in that case, then we're probably OK.

I was wondering if it would be possible and sensible to cache symbol_id -> symbol name lookups in additional hashmap/BTreeMap.
All the calls of prehashed in this PR should be avoidable unless we are given names of the symbols to export.

We could. I'm unsure if it would be a performance win or not though. How many times do we hash a symbol name in the common case? I'd kind hope that it would still be 1. For the extra calls that we make in less common cases, I guess we could run some benchmarks that hit those cases and see how much of a problem it is.

It may be possible to get rid of some unnecessary calls via other means. e.g. the call you're adding in compute_value_flags - that function is called from load_symbols which is the primary place where symbol name hashes are computed. So in that case, I could imagine passing a &mut SymbolInfo to compute_value_flags where SymbolInfo contains the &crate::elf::Symbol that we currently pass, but also an Option<Prehashed<UnversionedSymbolName>>.

Based on samply profile (with 10 000 Hz) when linking Clang using main branch with a single thread, prehashed() is called from:

• libwild::symbol::UnversionedSymbolName::prehashed inside libwild::symbol::PreHashedSymbolName::from_raw called by libwild::resolution::resolve_symbol inside libwild::resolution::resolve_symbols - 7.9% of samples
• libwild::symbol::UnversionedSymbolName::prehashed called by libwild::symbol_db::SymbolLoader::load_symbols - 3.2% of samples
• libwild::symbol::UnversionedSymbolName::prehashed called by libwild::symbol_db::SymbolLoader::load_symbols (again, looks like a different object given to Rayon?) - 1.6% of samples
• • libwild::symbol::UnversionedSymbolName::prehashed called by libwild::symbol_db::SymbolLoader::load_symbols (again, looks like a different object given to Rayon?) - 0.8% of samples
• ... and so on with libwild::symbol_db::SymbolLoader::load_symbols

So, looks like 2 calls sites. One of them is parallel already and the other one will be after #1003

Thanks for looking at that. Those two call sites should in theory amount to calling once per symtab entry. The call in resolve_symbol should only be for undefined symbols (references) and the call in load_symbols should only be for definitions.

Is this a TODO that you intend to resolve before merging, or something for later?

This was kind of "loud thinking" in case I or somebody who does the review gets any idea on how to improve it.

Would changing the version in version_script.rs to accept from_arg be an option?

Yeah, while not useful for version scripts, it deduplicates things a lot. So, probably worth the tradeoff.

This name repeats "explicitly" and "list_data" twice. The field above also has "explicitly" twice. I haven't thought deeply about the name, so feel free to disregard, but what about just export_list, explicit_export_list, explicit_symbol_exports or some similar variant?

Yeah, I had misclicked something in Helix and didn't notice the change (yay, feels like the early days in Vim). I have fixed it before seeing your comment, I think I'll go ahead with export_list.

While multiple calls for the same symbol could be bad for performance, I'd say what perhaps matters most here is whether we actually make that call most of the time. I'd assume that in the vast majority of linker usages, the list of explicit exports will be empty. So, if we can avoid calling prehashed in that case, then we're probably OK.

Dunno if we should somehow reorganise or perhaps extract the code that is shared between version scripts and export list.

Since there is other work around this area that is right now blocked by this PR, let's leave this discussion for later.