Jump to content
John Lokanis

Get Host Name performance issue

Recommended Posts

Here is a fun fact I just discovered:

 

If you want to get the host name of your machine in LabVIEW, there is a function for that:

post-2411-0-04123500-1446846555.png

 

If you want to get the host name using .NET, then you can call the method System.Net.DNS.GetHostName using an invoke node:

post-2411-0-13678500-1446846576.png

https://msdn.microsoft.com/en-us/library/system.net.dns.gethostname(v=vs.100).aspx

 

Now the fun part:

If you call each of these functions on a Window7 OS they execute fairly quickly:

 

LabVIEW Method: 0.000289767 seconds consistently.

.NET Method: 0.182981 first call, 0.000417647 seconds subsequent calls  (must be a cache)

 

Next, try the same thing on a Windows Server 2012R2 OS:

 

LabVIEW Method: 4.53384 seconds (WTF LabVIEW???)

.NET Method: 0.187395 first call, 0.000350523 seconds subsequent calls  (again, must be a cache)

 

So, let's say you are using the machine name at a unique identifier to manage a networked messaging architecture.  And as a result, you are often getting the machine name to tag a message you are sending with the sender's 'name'.  And you decide to run you system on Windows Server 2012R2 OS.  It will *work* but your performace will be down the tubes...

 

Any ideas on what could possibly be causing this?  I know I could come up with my own cache of the host name in my code and then access it via FGV or something simular, but that is no excuse for this dismal performance.

 

FWIW, there is yet another way to do this:

post-2411-0-37045300-1446846597.png

https://msdn.microsoft.com/en-us/library/system.environment.machinename.aspx

 

execution time: 7.91631E-5 seconds on Both OSes.

 

This leads me to the fact that a lot of the advice out there on this topic may need updating.

http://digital.ni.com/public.nsf/allkb/4B3877DB13370AA586257542003945A9

https://decibel.ni.com/content/docs/DOC-3917

http://forums.ni.com/t5/LabVIEW/Get-Computer-Name/td-p/101433

 

-John

  • Like 1

Share this post


Link to post
Share on other sites

Here is a fun fact I just discovered:

 

If you want to get the host name of your machine in LabVIEW, there is a function for that:

attachicon.gifget machine name snip.png

 

If you want to get the host name using .NET, then you can call the method System.Net.DNS.GetHostName using an invoke node:

attachicon.gifget machine name dotNET snip.png

https://msdn.microsoft.com/en-us/library/system.net.dns.gethostname(v=vs.100).aspx

 

Now the fun part:

If you call each of these functions on a Window7 OS they execute fairly quickly:

 

LabVIEW Method: 0.000289767 seconds consistently.

.NET Method: 0.182981 first call, 0.000417647 seconds subsequent calls  (must be a cache)

 

Next, try the same thing on a Windows Server 2012R2 OS:

 

LabVIEW Method: 4.53384 seconds (WTF LabVIEW???)

.NET Method: 0.187395 first call, 0.000350523 seconds subsequent calls  (again, must be a cache)

 

So, let's say you are using the machine name at a unique identifier to manage a networked messaging architecture.  And as a result, you are often getting the machine name to tag a message you are sending with the sender's 'name'.  And you decide to run you system on Windows Server 2012R2 OS.  It will *work* but your performace will be down the tubes...

 

Any ideas on what could possibly be causing this?  I know I could come up with my own cache of the host name in my code and then access it via FGV or something simular, but that is no excuse for this dismal performance.

 

FWIW, there is yet another way to do this:

attachicon.gifget machine name mscorlib snip.png

https://msdn.microsoft.com/en-us/library/system.environment.machinename.aspx

 

execution time: 7.91631E-5 seconds on Both OSes.

 

This leads me to the fact that a lot of the advice out there on this topic may need updating.

http://digital.ni.com/public.nsf/allkb/4B3877DB13370AA586257542003945A9

https://decibel.ni.com/content/docs/DOC-3917

http://forums.ni.com/t5/LabVIEW/Get-Computer-Name/td-p/101433

 

-John

 

I would guess a configuration issue in the network stack. The LabVIEW function calls into WinSock which then will query the DNS resolver to return the TCP/IP network name. The WinSock provider works with internal timeouts when quering other services such as the DNS resolver. There is no easy way to influence those timeouts from a WinSock client.

 

The .Net function most likely calls GetComputerNameEx() which queries some information in the registry that is usually updated with some largish interval in the background.

Share this post


Link to post
Share on other sites

Thanks for the info.  I suspected something like this.  I finally got the IT guys to dig into this and they found an issue with the NIC configuration and drivers on the VM.  (This VM is dual homed across our corporate network and a private testing network in my lab).

Seems that LabVIEW is much more susceptible to issues like this than other languages.

 

In the end, I changed my code to use the .NET call to the Environment.MachineName property.  And I took the further step to wrap that in a FGV that sets the value on first call and then returns it on all subsequent calls. This will protect me from any future issues that introduce a delay when getting this data.

 

post-2411-0-42025400-1447097937.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.