Improve performance - rewrite to run as a separate process

[mrlacey]

from marketplace:

This slows down the opening of large files significantly; even when said file has no references to resources!

There are a few things to investigate:

• Are the improvements that can be made to the current codebase?
• Can a basic check for resources to adorn be done when opening a file? This could be combined with a known list of files that may or may not have something to adorn.
• Something else?

Improvement would be particularly relevant to files with no resources to adorn as these files gain nothing from a delay. At least if a delay in loading results in additional information being displayed it can be slightly more easily justified

[MagicAndre1981]

In VS2022 17.9 preview (3 currently) I get this message all the time:

[mrlacey]

Something changed in 17.8 that either makes this slower or manes that the way the time is calculated makes this seem to the internal clock that this is taking longer.

I think the solution is a complete rewrite to move the code out of process. I was hoping that the new extensibility model would help make this easier but that still has no indication of when it will be usable in released extensions.
I've looked at the current ways of doing an OOP solution and they're very complicated and not something I have time to

I'm open to alternate suggestions for intermediate solutions such as skipping certain projects or only running on certain solutions.

The time taken is searching for and parsing the files. This is done off the UI thread as much as possible but lots of the old VS extension APIs require the UI thread. :(

Sadly, it's larger projects where this is more of an issue, but it's also larger projects where this is more valuable....

Note. This also affects ConstVisualizer too :(

[MagicAndre1981]

I think that OOP extensions will come as large feature in next major version (maybe VS2024) . I ignore this for now and click the message away.

[MagicAndre1981]

in 17.10 Preview 1 VS shows that the extension blocks VS for 25 seconds:

🤷‍♂️

[mrlacey]

in 17.10 Preview 1 VS shows that the extension blocks VS for 25 seconds:

🤷‍♂️

I've never seen a delay of that length. Is it a really big project or solution?
v1.21 was supposed to avoid this. I guess not. 😢

[MagicAndre1981]

it is around 30 projects. I loaded the complete solution to update the nugets after yesterdays patchday, normally I only load a solution with less entries (old desktop UI, UWP, MAUI when I work on a one smaller part)

I removed the extension and VS doesn't get frozen any longer and doesn't show a perf warning message any longer.

[MagicAndre1981]

I got a message that VS was blocked for 8s, in Output I see this info you've added:

Reloading list of resx files.
String Resource Visualizer initialized with 30 resource files.


a lot of resx file now


About to parse solution due to solution load.
Parse total duration: 00:00:07.5423493
About to parse solution after package load.
Parse total duration: 00:00:00.0367446

[mrlacey]

@MagicAndre1981 thanks for the update.

Because I'm doing things that VS insists happen on the UIThread I think the real solution is a rewrite.
I was hoping that VS Extensibility changes would make this easier but slow progress there (despite the changes in 17.9) means I really need to rewrite the way this works at a fundamental level. Eventually this will again mean another rewrite for VS extensibility changes in the future. :(

I'll continue trying to find any small improvements in the meantime, but as VS has become increasingly persistent in showing the warning you're seeing, you are free to uninstall or tell VS to stop warning about this extension.

Far from ideal but the best I can do right now. Of course, if anyone wants to help out by rewriting this extension to work as a separate, process connected to an extension, I'm happy to talk more. :/

[MagicAndre1981]

Here is the output from latest extension version:

About to parse solution due to solution load.
Parse total duration: 00:00:04.5506106 (active = 00:00:04.4827765)

[MagicAndre1981]

when I load a smaller part of the great solution (only the Android app part of the Xamarin Forms app, with the ns2.0 shared app code and a few other ns2.0 DLLs with common code) I see 16s delay but in output only short durations:

About to parse solution due to solution load.
Parse total duration: 00:00:01.2008082 (active = 00:00:00.3002088)

and the confusing thing is that the rex files from the WinForms client are still processed even if they are not part of the actual loaded sln:

Reloading list of resx files.
String Resource Visualizer initialized with 30 resource files.

Client\Forms\frmAboutBox.resx

So only load the resx files if they are really part of projects within the sln may improve perf for some solutions.

[mrlacey]

There's a separate timer tracking how long it spends parsing the resource files and that only reports duration if it takes longer than a second.

The time difference is why I initially started adding my own timers as I couldn't understand why the times it was claiming could ever happen.

My current thought is that there's a lock on solution/project load that is delaying the IO as I query the file system.

So only load the resx files if they are really part of projects within the sln may improve perf for some solutions.

Sadly, this is a big logic change as knowing which resource files are of interest would mean waiting for the solution/project to finish loading which has other knock-on effects on my current logic. For now, I just search from the root of where the solution file is. - Not perfect but mostly good enough.

The journey to improvement continues....