New but Obese software

[MogaRaghu]

I have been facing this problem of  very slow opening of VIs with LV8.0. You may not believe, but this is what happens :

- I double click on a ABCD. VI saved in LV8.0 on the desktop .
- LV8.0 launches with all fanfare and I am happy.
- Tens of seconds pass by and after some time WIN_XP decides that all is not well and issues a Error dialog saying the  ABDC.VI  is not found !
- Now LV8.0 is very ashamed and in a hurry launches the front panel of ABCD.VI covering up the WIN_XP dialog.

( My note book is a 2.5 Ghz P4 with 1Gb ram and very tightly optimized with  a compacted registry and hard disk scanned and defragged every 15 days . All other apps like Word open in a jiffy )

So, now I am even more convinced that there is no free lunch. As softwares develop with more and more of bells and whistles, they get fatter and fatter and to keep them running faster and faster companies like Intel works more and more to develop cores that run at blazing speeds. Then  heating is a problem. Not to worry. Clamp that  fat copper cooling fin on the CPU. Not enough ? Put in a cooling fan.. . Never give up or force the programmers to develop tight code. Not time for it.  I generally have a feeling that current day softwares are developed in a big hurry to keep the Time To Market  low and be one up over competition. But the low side of this is massive program codes that are not as compact as  they  would be  when  optimized over and over.

I  also code in assembly and C for microcontrollers. What performance I manage to get with 4k of assembly code will normally be achieved with a C code that is atleast  2 to 3 times or more that size. Its almost always Convenience Vs Size.

Not sure how many of you have faced this slowness "problem" with LV 8.0 but I defenitley have.

Raghunathan

[tbd]

I'm sympathetic, Raghunathan - (running 8.2 @ 1.2GHz.)

... but when you say "All other apps like Word open in a jiffy" I think: Yeah! but Word doesn't come with thousands of built-in term papers!

[tst]

Not that I disagree with you, but I would just like to point out that you can't compare a program running on a PIC developed by one person to a large development environment. The larger your project gets, the more you have to abstract and simplify your code. This often comes at the expense of performance. If LV 8.0 has to load a gzilliion toolkits when you open it, then it will take time to load.

As for a more practical answer, people have experienced that LV 8.0 takes a long time to load. The main culprits, if I remember correctly, can be either having a lot of toolkits installed or the license manager. There was an issue where the license manager would slow down the loading of LV 8.0 if your network cable was disconnected. I suggest you search here for things like "8.0 load time" or similar to see if you can find a solution (or you can try talking to NI support).

[altenbach]

What you are seeing is not normal, especially the "file not found" message.

As tst mentioned, LabVIEW 8.0 loads a bit slow and there could be other contributing factors. If you would upgrade to 8.20, you'll notice much faster loading.

Back to the problem. Try to open LabVIEW 8.0 first (how long does this take compared to above?), and then click on the file on the desktop. Is it still slow? What is the size of the VI? What antivirus program do you use?

[MogaRaghu]

I am glad that the giants have stepped in . And kind of acknowledge that LV8.0 is a bit tardy in loading. Now to the answers :

1. I use Norton Antivirus.
2. Opening LV 8.0 alone is faster. And selecting the  LV from  the recent list is defenitely faster.
3. The size of the VI does not matter when I double click it to open. Even a VI that is just under 50kB has the same problem, as LV8.0 takes its own sweet time to complete the "initialization" - whatever that means.
4. I fully agree on the abstraction part  when it comes to a multi-programmer environment.  But my question was : How sure are we that in the end we have produced a fully optimized code and not depend entirely on the CPU speed to do things fast ?? What I am trying to point out is the difference between obvious code and smart code. Do we have the time and programmers to develop code that is compact to the core and has no flab around ?

 Guys at NI don't take this seriously - I know what it takes to produce what you give us. Just thinking loud.....  

And incidently I have another question. ( whay waste another thread on it ? )

I have a code for a full machine that runs fine for a few hours and then for no obvious reason starts slowing down.  The architecture is a State Machine running inside a Timed loop set to run at 50mS.  But being a new machine I am still running it in design mode  ( LV 7.1 )

There are no arrays that build to a huge size in the background or  local variables / property nodes  inside  loops.  The time it takes for the code to slow down is also not uniform, and happens randomly. The timed loop stretches to 100ms and beyond. Quitting and restarting solves the problem for that instant.

I am at a loss to see whats wrong. Would I benefit if I just convert the code to an EXE ? Who knows when i run in  design mode if the CPU has to do some extra work and finally gives up ??

In simple terms, is  a VI as an EXE more stable than when run in a design environment ?

Thanks

Raghunathan

[altenbach]

---

@Raghunathan wrote:
In simple terms, is  a VI as an EXE more stable than when run in a design environment ?

---

Stability wise, they should be the same, but an exe typically has less baggage to load. For example all diagrams and most front panels are stripped out and debugging is normally disabled. An exe is also a bit more safe, especially if you do development work at the same time. For example, fo you write another LabVIEW program with a "quit LabVIEW" node and run it, it might affect the other program running in the development environment, but will not touch the executable.

About the slowdown:

Yes, building arrays without bounds would cause this, but you (maybe) eliminated that possibility. How about references. Do you e.g. open new references at each iteration an never close them? Are your output tunnels of the state machine set to use defaults if unwired? I've often seen references get lost that way so they can never be closed again.

If you look at the CPU and memory use over time, do you see a constant increase over time?

What does the program do? Any networking? Communication with instruments or other hardware?

[tst]

---

@altenbach wrote:

What you are seeing is not normal, especially the "file not found" message.

---

Actually, while the message is not common nowadays, it is perfectly normal.

When you double click a file, Windows calls the associated program to open the file. If after a certain time it does not get a specific response it returns that message and it is common to have the VI open, work on it and other VIs for a long time and only find the message after several hours. My impression from the original post was this was understood, which is why I did not mention it.

On my rather old soon-to-be-replaced laptop, loading LV 7.0 with all kinds of toolkits also produces this.

[rolfk]

---

@tbd wrote:

@I'm sympathetic, Raghunathan - (running 8.2 @ 1.2GHz.)

... but when you say "All other apps like Word open in a jiffy" I think: Yeah! but Word doesn't come with thousands of built-in term papers!

---

Another fact is that Microsoft cheats here. They firstly put lots and lots of the support libraries for their applications into the standard Windows kernel so once you load Word a lot of its dependencies are already loaded into memory and Word can just load its additional stuff.

Second they cheat once more by caching some of the application parts in a special system cache. The basic principle of this cache benefits most frequently launched applications but I'm quite sure Microsoft uses preferential treatment for their own applications in not trashing their caching as soon as others.

If you really talk about code bloat Microsoft software is usually beating LabVIEW hands down.

Rolf Kalbermatter

Message Edited by rolfk on 01-24-2007 08:30 PM

[pallen]

What you are seeing is not normal, especially the "file not found" message.

Actually, I get this message with 7.1 too. 

But, it only happens when I'm starting LV for the first time by double-clicking a VI.  Since LabVIEW does open the VI, Windows is incorrect reporting that the file isn't found. 

Once LV has been started, I can close it and double-click a VI file and the error will not repeat until reboot. 

[MogaRaghu]

Hello Altenbach,

The point regarding unclosed references is something that I can check specifically.

All output tunnels that  handle  AI,AO, DI and DO are carefully checked not  to use  "default"  data and are forced with  specific  data.

When the slow down occurs the Memory usage is not an issue but CPU usage climbs to 90% plus and almost reaches 100%.

The program is not in an network environment. It handles  a PCI 6229 card and updates about  8 AI , 2 AO,  and 38 DIO.  But I have to admit : The updates to the AIO and DIO happen via  Global Arrays that is in MAIN through the VIs that load in the sub-panel of MAIN, based on the user menu choice. All precautions to avoid race conditions taken.

There is  one other thing, which is the Chart in the front panel of all the VIs that load in the sub panel. This chart can at a time plot more that 3 channels and is updated inside the state machine ( ie. once every 50ms)

Does any of the above give some more insight into my problem ?

Thanks

raghunathan