LinkDictionary seems to really slow down ResXResourceReader

• .NET Core Version: (e.g. 3.0 Preview1, or daily build number, use dotnet --info)
• Have you experienced this same bug with .NET Framework?: Yes

Problem description: A large resx with 40k entries compiles to resource file very slowly ~ 30 seconds

Expected behavior: The same .resx file converted into a .txt file compiles very fast, under a second. Of note, the conversion is slow. I would expect that both actions should take about the same time.

I think the problem is the fact that the code is using a ListDictionary which states in its code comments

/// <devdoc> /// <para> /// This is a simple implementation of IDictionary using a singly linked list. This /// will be smaller and faster than a Hashtable if the number of elements is 10 or less. /// This should not be used if performance is important for large numbers of elements. /// </para> /// </devdoc>

Minimal repro:

1. Create a resx file with 40k entries and then run resgen.exe myfilename.resx ==>slow

2. Convert this file to a txt file using: resgen.exe myfilename.resx myfilename.txt ==> slow

3. Convert the txt file to resource dll using: resgen.exe myfilename.txt ==>fast

[rainersigwald]

No, and it’s part of .NET Framework SDK, which is unlikely to see major changes in the future. MSBuild owns a fork of the resgen.exe code, though, in our GenerateResource task. If this repros there, without resgen.exe, that bug would belong to MSBuild. But that doesn’t appear to be the case; GenerateResource worked over a 40k-resource-string resx in 308 ms on my machine.

If you can alter your build process to avoid resgen.exe (perhaps by unsetting ResGenExecuteAsTool or setting it to false) you might be able to avoid the problem.

[merriemcgaw]

We appreciate that this is a performance issue, but it isn’t bubbling up to the top of our team’s priority list. At this point we’re not sure where the problem is that @smorrell is describing. The work @elachlan is doing around replacing Collections may help in resolving this problem.