For MinGW, unique partial sections are much more common, e.g. comdat functions get sections named e.g. text$symbol.
A moderate sized example of this contains over 200K Chunks which create 174K unique PartialSections. Prior to SVN r352928 (D57574), linking this took around 1,5 seconds for me, while it afterwards takes around 13 minutes.
The std::find_if in findPartialSection will do a linear scan of the whole container until a match is found. To use something like binary_search or the std::set container's own methods, we'd need to already have a PartialSection*.
Reinstate a proper map instead of having a set with a custom sorting comparator.
A reproduction testcase can be found at https://martin.st/temp/vlc-qt-plugin-repro.zip.
On a second thought, and if we wanted to be optimal, I was wondering if we shouldn't be using a llvm::DenseSet here instead. std::map isn't known to scale particularly well with many elements, and you're at the implementation's mercy. At least the behavior will be more consistent with an internal structure.
I did use a DenseMap initially, but that requires more plumbing, because you need to retain the insertion order ( for later, when emitting data into the PDB). I did not see the advantage at the time, given that MSVC does not generate that many sections, but in your case, it matters. What do you think?