You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've noticed that mRemoteNG takes significantly longer (tens of seconds) to start on one of our VDI hosts, while showing Loading mRemoteNG. Please wait... message comparing to some other machines that we run. I captured a trace using WPR and found out that a significant portion of time is spent for a WMI call in mRemoteNG.exe!mRemoteNG.App.Initialization.StartupDataLogger::GetArchitectureData() method:
Looking at the sources I revealed that the query expression is actually pretty simple one:
"SELECT * FROM Win32_Processor WHERE DeviceID=\'CPU0\'"
However, testing how long this query executes on different machines I discovered that the execution time is proportional to the number of CPUs that a machine has.
Expected Behavior
Startup experience should be quick
Current Behavior
The load time increases proportionally to the number of CPUs that a machine has
Possible Solution
Update the query to return only the fields that are necessary
Steps to Reproduce (for bugs)
Get a server with a bunch of CPUs (i.e. a VM with a lot of single-core vCPUs) and start the tool
Context
Once we've migrated the tool to a more powerful VDI host (previous had only 2 vCPUs), we started experience longer startup delay.
Your Environment
Version used: 1.76.20
Operating System and version (e.g. Windows 10 1709 x64): Windows Server 2012 R2 Standard (9600)
The text was updated successfully, but these errors were encountered:
I've noticed that mRemoteNG takes significantly longer (tens of seconds) to start on one of our VDI hosts, while showing
Loading mRemoteNG. Please wait...
message comparing to some other machines that we run. I captured a trace using WPR and found out that a significant portion of time is spent for a WMI call inmRemoteNG.exe!mRemoteNG.App.Initialization.StartupDataLogger::GetArchitectureData()
method:Looking at the sources I revealed that the query expression is actually pretty simple one:
However, testing how long this query executes on different machines I discovered that the execution time is proportional to the number of CPUs that a machine has.
Expected Behavior
Startup experience should be quick
Current Behavior
The load time increases proportionally to the number of CPUs that a machine has
Possible Solution
Update the query to return only the fields that are necessary
Steps to Reproduce (for bugs)
Get a server with a bunch of CPUs (i.e. a VM with a lot of single-core vCPUs) and start the tool
Context
Once we've migrated the tool to a more powerful VDI host (previous had only 2 vCPUs), we started experience longer startup delay.
Your Environment
The text was updated successfully, but these errors were encountered: