Cold performance of ResourceManagerStringLocalizer is atrocious

[DamianEdwards]

Consider a localized version of the home page in the standard ASP.NET starter web template. You get around 50 localized strings. This results in 50 calls to ResourceManager.GetString that will throw MissingManifestResourceException when using the base language (i.e. one that doesn't have a specific culture assembly). That takes about 6 seconds. The next call is super fast as everything is then cached (~15ms).

Need to explore how we could possibly make that initial render faster.

[Eilon]

@DamianEdwards please round up some folks to come up with a plan for this.

[chemitaxis]

I have added a new issue, could be this in relationship with my issue? Thanks!

#252

[Eilon]

@ryanbrandenburg can you take a look to see where the time is being spent at startup?

[Eilon]

To be clear, this is about an app that is "localizable" but not "localized." But it would also be interesting to see what differences there are when the app is localized.

[ryanbrandenburg]

I don't see this terrible performance when running a test app from the console, but it IS really slow when run from VS (whether the debugger is attached or not). Console gives us ~10 requests/ms vs VS taking 289ms per request. Given that info, this sounds more like a VS bug than a Localization problem.

[rynowak]

Bear in mind the date this was reported, the underlying systems may have been improved. For instance if you were to attach a debugger and verify that those exceptions are no longer thrown at all (first chance) then that's a sign that the underlying issue was fixed.

[DamianEdwards]

@ryanbrandenburg how many localized string callsites were there in your test app?

[ryanbrandenburg]

I set up a double for loop going through 5 StringLocalizers looking for 100 different strings (1-100), so in total it looked for 500 strings which shouldn't have been in the cache.

Yeah, I'm keeping in mind that this could have already been resolved for the console case by another fix (even inadvertently) but I've debugged this and we definitly still throw the exceptions here.

[DamianEdwards]

Thanks. Seems it no longer repros then.

[ryanbrandenburg]

My best guess on the difference here is that the version of ResourceManager used in netcoreapp1.1 seems to be ~13x faster than the one in net451. The project I'm using to test this is both net451 and netcoreapp1.1, running 'dotnet run' was giving me netcoreapp and VS was defaulting to net451 and I didn't notice. I think we can close this one out as having been fixed.