In cases where you have many dylibs referenced by load commands, this
would be accessed repeated times for the same dylibs causing huge time
spikes.
Details
- Reviewers
int3 - Group Reviewers
Restricted Project
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Thanks for looking into this!
lld/MachO/DriverUtils.cpp | ||
---|---|---|
189 | nit: can we call this resolvedDylibPaths? Especially since there's loadedDylibs below which is actually storing DylibFile *s as values also maybe the comments on lines 218-219 could be hoisted up above this declaration | |
193–196 | how do you feel about using a similar approach to loadDylib below where we take a reference to the map value and then modify it? Aside from saving us two lines of resolvedDylibs[key] = file, it also serves as a negative cache -- if the key exists but the value is an empty string, then we can just return std::nullopt (I notice we don't actually do this negative cache checking in loadDylib, but I guess in that case it matters less since we don't expect that cache lookup to fail in the common error-free case) |
Improve naming, move comment
lld/MachO/DriverUtils.cpp | ||
---|---|---|
193–196 | I think I'm missing the C++-ism for how to do this, in this case the value isn't a pointer to a StringRef, can we still use it in that way or should it be changed to be that? Also right now a missing value / empty string won't ever get cached, do you think we should cache that in the fallthrough case to handle the negative cache case you're talking about? |
lld/MachO/DriverUtils.cpp | ||
---|---|---|
193–196 | You don't need a pointer, just a reference :) basically I'm suggesting this (inserted after lines 193-196 in your diff) auto entry = resolvedDylibPaths.find(key); if (entry != resolvedDylibPaths.end()) { if (entry->second.empty()) return {}; else return entry->second; } StringRef &s = resolvedDylibPaths[key]; // creates an empty string value entry for `key` And then below would be return s = saver.save(tbdPath.str()); |
modify value
lld/MachO/DriverUtils.cpp | ||
---|---|---|
193–196 | ah duh thanks, i was thinking there was supposed to be some way where i was only doing a single fetch here |
Looks like it doesn't actually help with https://github.com/keith/rules_apple_linker/issues/38 if I read that right (?)
yes, not yet. we don't have to land this unless it does for sure, so i'll wait for resolution there first
ignore empty entries since this is called multiple times with candidates, and we only want to cache the first hit really. It will still be empty and search in the case nothing can be found
nit: can we call this resolvedDylibPaths? Especially since there's loadedDylibs below which is actually storing DylibFile *s as values
also maybe the comments on lines 218-219 could be hoisted up above this declaration