Methods to break down large VI so that it runs faster

[johnsold]

I ran the profile tool on your program.  It shows the TDCluster AE.vi running almost a million times.  I do not see where it is called that often (or why).  Even though it is fast (average time ~ 1 us), the total time still adds up to about 2/3 of the total run time.  For this test I started the main VI, clicked Set Parameters, clicked Accept and Solve, then clicked Stop.  Total program time is about 1.2 seconds.  The AE time is about 800 ms.

Lynn 

[krwlz101]

Two things:

Where/how do I get/use the vi profiler?

And I too have no idea why it would call that vi that many times.  The laggyness is far worse when dealing with an input function.

The input function portion I am still working on though, so I am hoping that it's getting better.

[johnsold]

Tools >> Profile >> Performance and memory.

Also, if you post a later version of your program, please include some values of the System parameters which will produce a non-trivial result.  The ODE display shows NaN as the coefficient of x when I run it with the default values.

Lynn 

[JÞB]

---

krwlz101 wrote:
One more question (for now), is there a way to get an initialize, or first run type of event? As one could assume from my last post, I have some AE's storing data for me, and wanted to add an initialize case, so that I could use that to set some defaults. I would only want it to run the first time though.

---

Sorry I've been too busy to keep up- I'll post back on the code later.  But I did want to point you to the "First call" function.  It is a good function to use to make sure your first call to an AE initializes the data.  

[JÞB]

---

krwlz101 wrote:

Two things:

Where/how do I get/use the vi profiler?

And I too have no idea why it would call that vi that many times.  The laggyness is far worse when dealing with an input function.

The input function portion I am still working on though, so I am hoping that it's getting better.

---

Looks GREAT!  Two minor hits though.

1. Wire the outputs of the AE's that are outside the consumer loop to the consumer loop or put a structure around them.  You have no data dependance so the AEs may not be executed before the producer loop starts.
2. the consumer loop's event TOP tunnel is set to "use default if unwired" so EVERY event fires the default value "0"=Read-Solve-Display.  This is causing unintended RSD commands (and probably the performance hit mentioned above).  You might want a "Null" state that really does nothing when you want nothing done.  Yes the loop will iterate, a "null" command will be dequeued but.... its really hard to do nothing.  Alternately, you could enqueue 1 or 2 elements inside the event structure if you need to fire a different number of commands from each event. 

Really good looking code- don't forget to add VI documentation.  1000x improvement may be an understatement.

[johnsold]

Jeff,

Thanks for point 2.  I had noticed the default tunnels but had not followed through with the consequences.

Lynn 

[krwlz101]

OK,

I am really not sure which tunnel in the consumer loop you are talking about.

What I think you are saying I need to do however, is add a blank state to the state machine?

Or is it the top tunnel in the producer loop that is the issue?  The one that only fires a command in one event?

[JÞB]

---

krwlz101 wrote:

OK,

I am really not sure which tunnel in the consumer loop you are talking about.

What I think you are saying I need to do however, is add a blank state to the state machine?

Or is it the top tunnel in the producer loop that is the issue? YES The one that only fires a command in one event?NOPE it fires every event

---

It fires a command it EVERY event- you cant have a blank value in a tunnel so, when you "use default when unwired" you do get a default value.  In this case it fires a RSD command from every event exept the one you wired a contstant to. 

The better solution is to enqueue indide the event structure-  That way a different number of commands could be fired from each event.

Message Edited by Jeff Bohrer on 03-17-2010 01:23 PM

[krwlz101]

I originally had coded it with the events inside the consumer loop, and though that it was poor coding, since the consumer loop was producing events. 

I will probably revert to that, since it seems much simpler and straight forward.

[Mark_Yedinak]

A single event in the producer can queue multiple states as well. There is no problem with the consumer queueing states. (Though Ben would argue that a queued state machine is not a true state machine.)