Understanding code complexity

[BTC_Admin]

If you already know that your events structure is the culprit, one thing you could try to do is minimize amount of things you do inside an events structure (if you're familiar with C/C++/C#/etc traditional languages, best practice is to do take care of interrupts as quickly as possible - I'm meaning to imply the same concept here for events structure).  Less you do in an events structure, better the performance is - I even avoid any front-panel updates (such as manipulation of visible property) or time-consuming items like string manipulations/etc inside an events structure.

-DP

[Intaris]

I appreciate the input but:

1) My "problematic" event structure is the CONSUMER loop in my producer consumer design.  It is dealing exclusively with user events.  UI Events (to which you are referring as Interrupts) are handled in a seperate loop which does approx. zero actual work.  Yeah, I have two different loops with event structures and no, I share no events between them (Unless you include "Timeout").

2) My problem isn't with execution, performance is fine.  The question I have is the "code complexity" being shown by LV 2012.

Shane.

[BTC_Admin]

You did not understand my point - I was referring to usage of "event structure" itself, irrespective of which loop it was in. Reference to interrupts was simply an analogy (hence "meaning to imply the same concept"), to convey that code complexity seems to be affected by how / how much code you implement inside event structures versus using other (non event structure) methods as much as possible - a part of caveats when using event structures.

Anyway, good luck.

-DP

[Intaris]

And my counter-question would be why would it make any difference whatsoever if you have an event structure or simply a while loop with a queue.  The complexity is essentially the same.

If you mean simply doing less in loops, then yeah, that's kind of obvious that that'll impact complexity.  Whether the main loop feature is an event structure or not makes no difference for me.

[Intaris]

---

BTC_admin wrote:Less you do in an events structure, better the performance is - I even avoid any front-panel updates (such as manipulation of visible property) or time-consuming items like string manipulations/etc inside an events structure.

---

Execution speed is not very closely correlated with complexity.  Some very simple code could be very slow and some very compelx code could be very fast.

[PaulG.]

These numbers wouldn't  bother me at all. Most of your "complexity" and increased memory usage is coming from the newer version of LV you are using. A lot has been stuffed "under the hood" since version 7.1.

[Intaris]

I could accept that no problem if the comparison in size wasn't made in the SAME LV version.  Sure, the origins of the VI are way back in 7.1, but the numbers I'm comparing are both in LV 2012.

[GregFreeman]

Im not sure how much id worry about complexity. That seems fairly subjective. Is it from a compiler point of view or a programmer perspective? Occurences are about the lowest level you can get so i coild see a pc saying thats less complex when from a readability standpoint it may be more complex. As to the size, im not sure. I would be curious how queues compare to the event structure and occurrences, kind of as a middleman.

[Intaris]

Well it's a problem in that it takes more memory and time to compile.  We're already at times at the limit of what a 32-bit machine can compile to be honest, so I was hoping to be able to reduce complexity a little to help ease the pain.  Apparently it won't help because I tried pasting into a new VI, same story.

I understand that the measure of complexity is a number generated by the compiler based on what it can easily and less easily optimise.  As such, reducing complexity should make for a more painless compile experience.

[tst]

I can't answer the question, since I never looked into the exact details on code complexity (although I believe there are fairly detailed articles on the topic elsewhere on this site), but if your problem is with compile times, you could consider lowering (or is it raising? Read the docs) the optimization slider in the 2012 options, which I understand makes its decision based on the code complexity metric. The tradeoff is that the performance might suffer.

Another option might be to farm out the compilation to a dedicated server (either your own or I think NI provides this as a service, although I don't know if that only applies to FPGA. You could also try asking Jack Dunaway who demonstrated working on Amazon's remote machines).