Bugzilla 24700 - Don't search for mscoff .dp$B section over and over

[dkorpel]

Compile time goes down from 42.5s to 2.8s when compiling this:

static foreach (i; 0 .. 8_000)
    mixin("struct S"~i.stringof~" {float x;}");

__gshared int*[64_000] x;

Not closing the issue yet, because it's still doing O(n) section search in general making it slower than needed.

[dlang-bot]

Thanks for your pull request and interest in making D better, @dkorpel! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the coverage diff by visiting the details link of the codecov check)
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✗	24700	normal	MsCoffObj_getsegment is really slow O(n^2)

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub run digger -- build "master + dmd#16780"

[rikkimax]

Assuming this is a singleton, it perhaps would make sense to have a table of them.

[dkorpel]

Please clarify 'this' and 'them'.

[rikkimax]

this = .dp$B

them = sections

[dkorpel]

Yes, in the issue I mentioned how mscoff should use a hash table for sections just like elf, hence this is not closing the issue yet.