For Loop slows down when application is made into EXE

[tylers32]

I have a large application that uses a For Loop to perform channel calculations. Inside the loop is a case structure for the various calculations.  There are some calls for global variables and many coercion dots inside of this loop.  The loop run-time takes about 2-3 seconds to complete each run when the source code is operated.

However, when the code is compiled into an executable (LV 8.5) the run-time takes about 40-60 seconds.  The compiled version of the same code in LV 8.5 runs normally (2-3 seconds).

Is there a bug or some operation in labVIEW 8.5 that is causing the compiled version to run so much slower? I would like to keep up to date with the latest version of labVIEW but each time I upgrade there are always problems like this.

Anyone have any suggestions?

Thanks,

Tyler

[Odd_Modem]

Without see your code I would suggest:

1. Converting more of the code inside the loop to sub-vis and set execution priority as sub-routine.
2. Replace the global variables with LV2 globals and remove any local variables.
3. Profile the run and optimizing the sub-vi that are called most frequently.

[altenbach]

No, a slowdown by a factor of 20 is definitely not normal and the above suggestions would probably not make a big difference. I suspect your problem is deeper than that.

Are you running and timing the executable on the same PC? Are any resources located on a network location?

Since you use LabVIEW 8.5, you can enable debugging for the executable. Maybe this can help pinpoint the problem.

(See http://digital.ni.com/public.nsf/allkb/3087D91EEADBAF3D862571D1004AF192)

You also rambled about "newest versions" and such. Does this mean that the same code did not have this problem in the previous LabVIEW version? This would be important to know!

Since you mentioned globals and coercions, the problem could be due to race conditions that manifest themselves due to a slight change in execution order, e.g. due to the removal of debugging code. I am curious why you have so many coercions. Coercions from what to what datatype?

Does your VI contain any "curret VI path" primitive?

Cna you show us some of the code to give us a better picture of what we are dealing with here?

Message Edited by altenbach on 10-21-2007 09:04 AM

[tylers32]

Thanks for the ideas.  After looking into the code more I think the problem was a combined effort of 2 problems:

1. One case had an iterative calculation with no limit so with certain inputs it would continously run. Fixed this by limiting its iterations.

2. Coercion of data-types that happend in numerous common cases. 

Fixing those two issues, the code was able to perform this process in about 3.5 seconds which is around the same time it took in LV8.2.  I attempted to improve the timing by fixing more coercion dots (using the data-type conversions) but this actually increased the process time to around 5 seconds.

Just to answer some of the questions altenbach had: 

1. yes, running and timing on the same PC and no network resources are used.  

2. Yes, the same code worked well in 8.2 but not in 8.5. 

3. Coercion dots are from poor planning and programming (this code is old, started in LV 6 and has had numerous people (non-programmers) working on it.  The typical data-type coercion was from DBL to I32.  

4.  The "current VI path" primitive does not exist in the code.

Thanks again,

Tyler