It looks like there's a little bit of logic going on behind the scenes. When I run your program as-is I don't see any change with it on or off, but it's writing the same value to the indicator for every iteration of the For loop. If I change it so the i terminal of the For loop is writing to the property node, there is a significant difference in performance.
There are many factors into the performance improvement here. One of them is how busy your front panel is. But I can speak in the general case here.
1. The Defer Front Panel call forces the panel to be redrawn. This is regardless of the state you write to it.
2. Every time you write to a property node for something on the front panel when the Defer Front Panel is turned off, the panel will be redrawn.
So if you are writing a lot of properties, such as individually coloring each cell in a table, you will want to use the Defer Panel Updates.
In your case, the panel is pretty empty and you are just updating a simple value. Therefore I would expect minimal improvements.
Your FOR loop might be optimized away by the compiler because the inputs are invariant during the loop. It would be better to ensure that the data actually differs between iterations. Still, writing to property nodes is synchronous and involves the UI thread even if the FP does not update. If you would replace the property node with a local variable, it would be many orders of magnitude faster. What is the purpose of all this?
In my experience, defer panel updates is useful for e.g. coloring fields of a large table individually . Here defer panel updates makes a huge difference
@altenbach: I build general GUI framework and that's why I need Property Node.
Well, there is never a reason to mindlessly hammer a property node millions of times per second, so make the code smarter to ensure these property nodes are only updated at reasonable intervals, e.g after the tight FOR loop in the above case.
The term "GUI framework" is too vague to suggest alternatives. It does no mean anything.