LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2009 slow performance

Hi Bob,

 

Are you seeing your memory grow as your application starts?  What are you doing in the program?  Is there a lot of initialization code?

Jared S.
Applications Engineering
National Instruments
0 Kudos
Message 31 of 51
(2,942 Views)

A simplified project looks like this:

 

EMI Temps.PNG

 

In other projects there is more than one shared variable (a very large string). The DLL is a simple linear search device used to pluck out variable values tied to measurement names in the for <Value Name>;<Floating Point As Double><CR NL>.

 

Memory use is not that extreme. Much busier projects of the same type seem to use a grand total of 55 MB as a binary. This is consistent with useage I've seen with Windows XP. Most of that is the Libraries and LabVIEW loading as a sort of virtual machine. The OS can not really separate the two consistently likely due to the dependency of binaries to load a whole lot of the guts of LabVIEW to run at all. In cases where there is more than one network variable I concatinate them together before tying them into the DLL due to the need to only have a single copy of the DLL during operation. I've seen more than one copy of a DLL opened by a VI cause unstable operation in the past.

 

Bob

0 Kudos
Message 32 of 51
(2,909 Views)

I'm going to apologize in advance for not being horribly familiar with your application, but are you dealing with an external data source that is returning a very large string? (I guess I'm wondering why we are just using one huge variable to hold multiple values)

 

I'm not quite clear as to where you're seeing the slowdowns at run-time, either. Is it a cumulative process, or all at one point in the startup process?

 

One thing you can try to isolate the problem: replace the DLL with an equivalent LabVIEW function and see how it affects performance.

 

string parsing.png

Message Edited by charris on 05-17-2010 04:36 PM
Caleb Harris

National Instruments | http://www.ni.com/support
Message 33 of 51
(2,873 Views)

My original reason for using the DLL in the first place was due to issues of performance. The search was slow and the DLL was initially faster. With modern PC performance a linear search widget can waste cycles and still end up faster in some cases regardless due to LabVIEW's increadible overhead. I suspect that while you guys are focusing on the mixed language approach being the problem it is more likely a delay in loading due to the Network Variables deployment and infrastructure slowing everything down unless NI has purposefully hobbled .NET development intermingling with LabVIEW.

 

So the question then becomes for you gurus out there: Which is it? Is there suddenly an issue with mixed mode development just to make it "available but useless" or is there a whopping performance penalty included with each new release of LabVIEW?

 

I tried the above example and I'm still messing with it. I'll let you know...

 

Bob

Message Edited by EWTech on 05-18-2010 10:12 AM
0 Kudos
Message 34 of 51
(2,843 Views)

The vi shown above has absolutely no effect on performance or startup time at all. Now there are other issues:

 

When I first received the 2009 version I tried a few binaries of applications built on the other development box in the lab. Right after installing the binary applications on the other PC it's clock went crazy and become incredibly unstable. I thought it was an issue between the driver, Windows XP and something in LabVIEW that had changed handling of hardware in the OS. At the time I expected that this issue was specific to the hardware in the machine showwing the problem.

 

After building and running binaries for the code above on the machine the apps were built on using SP1 of the 2009 software the system clock on the build/development machine is doing the same thing. Both machines use an Intel chipset with integrated video. They are at least three generations apart as the build machine is a P4 2.8 GHz PC built by IBM and the second is a Core 2 Dell machine. I complained about this before and was told that this was unlikely in the extreme. Neither NI or Dell said that this has ever been seen before. Dell doesn't support applications, just the hardware. NI just supports the software...

 

Has anyone else seen this? I might be able to say the thing was right twice a day if it would stay in one value over the course of the day! IT DOESN'T.

 

Bob

Message Edited by EWTech on 05-18-2010 03:19 PM
0 Kudos
Message 35 of 51
(2,821 Views)

Here is the edited and working version (very close) to what Caleb wrote:

 

String Value Lookup.PNG

The C# DLL uses the String.Split() function to do pretty much the same thing:

using System;
using System.Collections.Generic;
using System.Text;

namespace StringToVars
{
    public class StringToVars
    {
        String InString;
        int Count;
        public StringToVars()
        {
            InString = "";
        }

        public void Update(String vars)
        {
            InString = vars;
        }

        public Double GetValue(String var)
        {
            String[] temp;
            Double Value;
            String[] List = InString.Split('\n');
            foreach (String s in List)
            {
                if (s.Contains(var))
                {
                    temp = s.Split(';');
                    Value = System.Convert.ToDouble(temp[1]);
                    return Value;
                }
            }
            return 0.0;
        }

        public int VarsCount()
        {
            String[] temp = InString.Split('\n');
            Count = temp.Length;
            return Count;
        }

        public String All()
        {
            return InString;
        }
    }
}

 

 

Bob

 

 

0 Kudos
Message 36 of 51
(2,807 Views)

Hi Bob,

 

When you say that the computer's clock started to go crazy after installing the binaries, are you running the application in question?  Or is this just the idle clock of the computer?  Have you been able to see what process is using the most CPU?

 

Also, to answer your earlier question, the reason that we were looking at the DLL is that loading an extra DLL will always affect the start up performance of an application, whether you're working in LabVIEW or C++.  This would have been especially true for a large DLL, but that doesn't seem to be the case here.

 

If you go to Control Panel » Administrative Tools » Services, do you see the National Instruments Variable Engine set to start automatically?  Or is it set to manual? 

Jared S.
Applications Engineering
National Instruments
0 Kudos
Message 37 of 51
(2,761 Views)

Answers to questions in order posed...

 

The clock I am refering to is not the pulse train used by the CPU. That is the CPU clock. On most main boards there are likley several used for different busses. What I am refering to is the time clock maintained by the system and set using the BIOS. This is a date and time structure indicating what the real-world time is (somewhat).

 

As to the second statement this is a very small DLL. Note that I replaced this in Windows XP with the LabVIEW search function Caleb supplied and this had no effect on startup time. This improved things quite a bit on the Vista system. This is somewhat problematic as there are a number of problems creating binaries that work well on both Vista and XP. Rendering of widgets on the Vista system is a mess running the original XP targeted code though it works for the most part. It looks a lot like I will have to obtain a copy of Visual Studio 2008 to get those applications to do the right thing in Windows Vista at all. For some things I have relied on Measurement Studio and am not about to give it up. Some things are just easier for me in Visual Studio than using LabVIEW. Mixed mode development USED to work fine with LabVIEW...

 

As to the last question I will have to defer this until I get the systems started up back in the lab. The XP system is off right now and I was working on updating the existing code to test on Vista which seems to like LabVIEW 2009 SP1. The only irritant is the wait of more than a minute when opening a VI for editing. I may have the memory upgraded on the machine to 4 GB. This is a Core 2 machine so it should be somewhat faster than the Pentium 4 machine that is currently running XP. I don't need a gamer class video card to edit vi code, do I?

 

Many thanks,

 

Bob

Message Edited by EWTech on 05-20-2010 09:48 AM
Message Edited by EWTech on 05-20-2010 09:51 AM
0 Kudos
Message 38 of 51
(2,741 Views)

A couple of things we've noticed:

 

  • Using the Project Explorer "Find" feature (control-F) causes the development environment to get very sluggish (noticeable delays switching between block diagram and front panel, etc.). Runtime speed is not affected. This is a bug.
  • .NET performance appears to be quite slow. Our basis of comparison talking to an SQL Server database using ADO via ActiveX vs SqlDataReader in .NET. The SqlDataReader is 20-30 times slower than ADO. (SQL Server Management Studio, which uses the same .NET APIs, is faster than LabView + ADO, so I don't think it is Microsoft's fault.) My guess is that NI is optimizing .NET compatibility over performance. Minimizing the number of LabView <-> .NET round trips is probably the best way to address this.

 

0 Kudos
Message 39 of 51
(2,722 Views)

Rob,

 

I have yet to use the Find feature as everything goes into the project files which seems to locate dependencies just fine and I assume that is what this would be for.

 

Can I ask what version of .NET you are working with? I've been using VS 2005 and .NET 2.0. The next generation (3.x) seems to be supported in LabVIEW but I have not used it yet. I may have to go to VS 2008 as we may soon be forced to use Windows Vista or Win 7.

 

Bob

0 Kudos
Message 40 of 51
(2,713 Views)