optimize an application

[MarcosBelgo]

Hi Friends,

In my application, I have a for loop that checks each row of an array and overrides a given field according to a rule. This application shows the results through a table. However, according to the amount of data, this check is taking too long! Is it possible to optimize this? For example, in a query to the SQL database, it is possible through an UPDATE talbe SET, to replace fields of an entire table virtually instantly, even though it has millions of data. However, through my application, every ten lines checked took almost 1 second to make a ridiculous rule of average .......

Thanks

[tyk007]

Perhaps you could post the VI(s) concerned - there many be many things that can be altered to increase performance but it will be hard to give the right information without seeing what you have thus far.

[MarcosBelgo]

Hi,

Here is the VI. 

[tyk007]

Unfortunately I only have access to LV 2012 right now and I see that the VI is in 2016.

But I can give some advice. I see that you have color highlighting of your rows in the table which you presumably do programmatically - and are probably doing in the same loop as your "verification" logic. Updating the UI is a relatively "slower" operation and, if its in the same loop as your verification update logic, will slow down your overall throughput. From a bench-marking perspective have you tried removing the UI update part and seen what the difference is?

[tyk007 · Accepted solution]

A colleague back-saved this VI for me so I have been able to take a quick look. As I suspected you are modifying the Table UI properties inside your loop which effectively reduces your throughput. LabVIEW has to keep making context switches back and forth from the UI thread (significantly increasing the overhead of each loop iteration).  Updating the UI is a relatively expensive task for all applications regardless of language - your comparison to SQL Server is a bit like comparing apples to oranges since the server has no UI, just the headless DB engine.

Attached is an updated version with a single change which removes the UI updates out of your tight "verification" loop and instead passes the necessary data onto a separate loop to manage the UI. This reduces the amount of context switching you are performing and improves the throughput of your routines without making any other changes. There are some other improvements you could make (such as defering panel updates to reduce table update flicker and improve the UI thread performance) but this will be the biggest.

EDIT: Added a version with Defer Panel Updates added

[MarcosBelgo]

Very thanks friend, Your code works very very fast!  

[Yamaeda]

String operations are 'heavy' so moving them outside of the loop makes a big difference. Parallellizing the loop also helps. This modification runs on ~0.3s

/Y

[tyk007]

Out of interest: if we try bechmarking all of the improvements step by step (100 iterations) with debugging disabled; on my 4 logical processor machine @ 2.7GHz the results are:

Your original code:

- With UI shown mean of 8823ms, sigma 118.10ms (@100 iterations this took a while to get!)

- With no UI shown (SubVI closed) mean of 28.48ms, sigma 4.41ms

Just moving the UI updates out of the main FOR loop (my original one):

- With UI shown mean of 70.01ms, sigma 10.10ms

- With no UI shown (SubVI closed) mean of 6.92ms, sigma 1.63ms

Additionally moving the constant logic outside the FOR loop (Yamaeda's addition):

- With UI shown mean of 69.80ms, sigma 10.93ms

- With no UI shown (SubVI closed) mean of 7.79ms, sigma 1.30ms

Additionally setting Parallelisation of FOR loop set to 4 to maximise logical CPU usage:

- With UI shown mean of 71.07ms, sigma 11.93ms

- With no UI shown (SubVI closed) mean of 6.89ms, sigma 0.93ms

This goes to show a few things:

• Windows lack of determinism (due to the OS scheduling) makes accurate bench-marking difficult; especially when the UI is being updated. Yamaeda's change with the string logic should have made a reasonable improvement but in this instance the change is mostly hidden in the OS scheduling. I would think though that if the number of items in the array increased this would start to make more of a difference.
• Your VI Front Panel implies that you will want the UI visible. So while the bench-marking is more consistent without a UI your use case says that we should only factor in the times with it present. Also adding iteration parallelism will mean that your progress bar will not work as expected and you will need a new mechanism to determine progress through the array.
• All the logic in the FOR loop is CPU bound so there is no point in increasing parallelism further than the number of logical cores - that will simply involve more context switches and actually make the whole process take longer. In this case moving the UI updates out of the loop made the largest improvement.
• Parallelising a FOR loop under the covers must have some special management of updates to the UI thread as Yamaeda's 300ms benchmark shows. However it seems less efficient than executing the UI logic purely as a single clump in an extra FOR loop.
• I can guarantee that anyone else who tries the same benchmark on identical hardware will get different results! This is one of the very hard things about benchmarking in a non-deterministic OS. The best conclusions you can draw are the relative impact on execution time for a change but once you get less than 10ms you are operating within the OS scheduling time.
• Only benchmark when you think there is an issue and treat all benchmark values with suspicion