recursion performance

[merula]

RavensFan,

sorry for the late reply (had vacation and a lot of stuff to do before that). 

Unfortunately I am not able to reproduce how I build this vi. I started with the example at http://www.ni.com/white-paper/9387/en. This is defective (different number out terminals in the vi itself and its recurive calls). But even if I start with the defective wiring I end up with a correct working version. I will try to to investigate this a bit further.

I use LV 2012 SP1 (not sure which fix).

I would appreciate if this is investigated by NI any further, because I do not want this problem to occur in a real project.

Regards

Lars

[Yamaeda]

---

@merula wrote:

Hi,

[SNIP]

case 0 and 1 are just wired through. The VI is marked as "shared clone reentrant execution".

[SNIP] 

When I run these programs the Python script takes about a second for n=30 whereas I had to kill the LabVIEW script after 3h where it already consumed 1.5GB RAM. I am aware that there are algorithms which performs better and I wont expect LabVIEW to perform as fast as the Python script as the overhead for the recursive call is probably larger for LabVIEW than it is for Python or C. Did I do anything wrong or is using excessive recursion in LabVIEW just not a good idea?

---

I take it you had a breaking case in LV and didn't run in highlight mode or retain values? 🙂

Does it perform diferently if you use the other reentrant option?

/Y