IADS performance with many objects

[Wolfgang]

Hi everybody!

We use many TEXT Objects with more than 1 dynamic onour analysis
windows. The Display Update Rate of some windows is below 1, even if
nearly nothing happens. Most of our TEXT Objects are driven from
derived parameters. These parameters use other derived parameters and
TPP parameters as source. Most of the TPP parameters do not appear
periodic (there might be half a hour no TPP at all, and the the
parameter appears 5 times a second),

I tried to find the bottleneck, but it seems to be the number of test
objects on the window. It did help a little bit to set the Update Rate
of the individual TEXT Object.

To test the performance with different nubers of text objects and
different numbers of dynamics per test object I build a config file
"pfConfig.DisplayUpdates.config". You can find it here at
"Dateien" (might be files or whatever in your language). Try it and
give me a hint how to speed it up.

Have fun
-----------------------------------------------------------
--- Wolfgang, SYS500 Model550, IADS 6.1 ---

[James Bretz]

> To test the performance with different nubers of text objects and
> different numbers of dynamics per test object I build a config file
> "pfConfig.DisplayUpdates.config". You can find it here at
> "Dateien" (might be files or whatever in your language). Try it and
> give me a hint how to speed it up.

Got it... Thanx,

Jim

[James Bretz]

Wolfgang,

There is a holiday here in USA, so we will check this out on Monday and get
back to you.

Sorry for the delay,
Jim

[Brenda Rasmussen]

Hi Wolfgang,

On Nov 26, 9:09 pm, "James Bretz" <j...@iads-soft.com> wrote:
> Wolfgang,
>
> > To test the performance with different nubers of text objects and
> > different numbers of dynamics per test object I build a config file
> > "pfConfig.DisplayUpdates.config". You can find it here at
> > "Dateien" (might be files or whatever in your language). Try it and
> > give me a hint how to speed it up.
>

I've taken a look at your test config file. Nice job building up the
example Analysis Windows. I'm seeing the same thing you are with
basically 1-3 updates (or less) with the 1400 Text objects with 5
parameters hooked up to 5 different properties. If I compare that
window to the AlphanumericTable window that has 1600 'cells' on it,
the update rates are drastically different. One of the main reasons
is that the Text objects are set to update as 'fast as they can' with
a property setting of UpdateRate = 0 by default. The Alphanumerics
and AlphanumericTables on the other hand are set to update 2 times per
second by default.

To see the effect this has on your Analysis Windows, on the
AlphanumericTable window, select all the displays then linger your
mouse over 1 of the cells and hit the 'u' key. It will change all the
display's update rates from updating 2x per second to
'ungated' (update as fast as they can). You will see the overall
update rate of the Analysis Window drop significantly. On the window
with the 1400 text objects, you can right click on one of them and
under the 'Edit' option, choose 'Select All Displays of this Type',
then bring up the property dialog and change the UpdateRate from 0 to
2. This wil cause the displays to only update 2x per second. You
should see the update rate increase in this case.

We're still looking into why the overall update rate for the windows
seem to be so low but it might just be the shear number of displays
you have on the window. Can you tell us what you're trying to do with
that many text objects in 1 window? If we have a bit more background,
we might be able to come up with a different solution for you.

Brenda

[James Bretz]

Hi Wolfgang,

Ok, sorry for the delay. Let me break down your example:

Laptop used for test: Dell XPS M1710, Intel Core 2 T7600, 2.33 Ghz, 2GB Ram,
NVIDIA GeForce Go 7950 GTX

1) AnalysisWindow AN_400

400 Alphanumeric objects
AlphaNumeric refresh rate set: 2/Sec.
Total Aw update rate: 64

Issues/Comment: None


2) AnalysisWindow one_dyn_1400

1400 ActiveX Text objects
ActiveX text refresh rate set to: As fast as possible (0)
Total Aw update rate: 1-5

Issues/Comments:

By default, all ActiveX objects are set to refresh at a rate of "0". See
property "UpdateRate". Yes, this is a little confusing to note that the
AlphaNumeric display defaults to 2 updates per second. To make this
experiment close to the previous, I set their update to "2" (stopped AW,
rope selected all Ax Text displays, right click->Properties, set UpdateRate
to 2, close, restart AW). After modification: Total Aw update rate: 15 - 40
but erratic. I would imagine this would be smoother with actual data (vs
simulated equation). Also note that we've increased the number of displays
be a factor of 3.5. That is certainly going to make a difference.


3) AnalysisWindow five_dyn_1400

1400 ActiveX text objects
ActiveX text refresh rate set to: As fast as possible (0)
Total Aw update rate: 0-10

Issues/Comments:

Again, same issue as above. All UpdateRate properties set to "0". After
resetting them to 2, I got around 1-15 updates per second, but again it was
very erradic. As I noted earlier, the simulated equation takes some time to
process. If you want to eliminate that from the equation, try repeating the
experiment with real (live) data.


Ok, now let's get back to the issues at hand.

> I tried to find the bottleneck, but it seems to be the number of test
> objects on the window. It did help a little bit to set the Update Rate
> of the individual TEXT Object.
>
> To test the performance with different nubers of text objects and
> different numbers of dynamics per test object I build a config file
> "pfConfig.DisplayUpdates.config". You can find it here at
> "Dateien" (might be files or whatever in your language). Try it and
> give me a hint how to speed it up.

Yes certainly, the total number of ActiveX text objects on the screen at
once certain does have a factor in update rate. The number of displays, how
fast the value changes, the number of individual dynamics set up on each
display, the sample rate of the parameter, the complexity of the derived
equation, and many other factors have effects as well.

On the most complex AW (five_dyn_1400), if I decrease the amount of ActiveX
text objects to 700 and set their update rate to 2, I'm getting around 15 to
39 updates a second. Again, this update is rather erratic because of the
derived equation being calculated in PostTest. If this were actual data, I
would expect it to be much smoother.

Having said all of this, 1400 text objects on the screen simultaneously is a
large amount (larger than usual). I think the best technique might be to
lower this amount down and split it up between individual pages using the
"DisplayFolder". You can probably get 500 text objects on each "Tab" and
then comfortably switch between the tabs when needed.

As for possible optimizations, let me tell you what's going on under the
hood for ActiveX text objects:

1) The Text object updates at the rate specified by the "UpdateRate"
property. The lower this number is, the faster the overall update rate....
but obviously you can't go much lower than 1 or maybe 0.5?

2) The Text object only updates if the value changed from the last draw. You
mentioned that your values don't update very frequently. If this is so, then
the entire cost can be attributed to data access.

3) The Dynamic system is only run when the Text object updates. In other
words, if you create a custom function to calculate the text conversion,
you'll be forced to do so at the "sample rate" of the parameter. This is
most likely a lot higher than the actual refresh rate so I'm not sure that
would be advisable for performance reasons.

4) Although you are using TableLookup for your Dynamics, you only have 2
items in your table. As you might have discovered, it might actually be
faster with a non table lookup in this situation. In the end, I don't think
this will have much effect on the outcome.


Now let's go to the comparison with the AlphaTable:

5) The ActiveX text object is much more complex than the AlphaTable. It has
an entirely different interface in order to get data into the display (i.e.
via the Microsoft Dispatch property interface). The data is actually being
"pushed" from the outside into each individual property. This interface is a
lot more flexible because each minute detail of the Text object can be
driven with data/dynamics, but take a lot more processing power. The
AlphaTable pulls the data directly from our data interface (parameter) and
draws it directly to the screen (a lot quicker but less flexible).

6) The AlphaTable can contain many displays within it's boundary. In your
example, you have 100 text objects in 16 AlphaTables. Compare this to 1400
individual ActiveX displays. In essence, we only have 16 displays with 100
parameters attached. If you had 1400 AlphaNumeric displays, I would imagine
the rate would be closer to the ActiveX example. Again, the total number of
simultaneous displays on the screen does dictate the processing
requirements. Each display must be processed on the screen every update
cycle. The more displays, the more time it will take (there is a fixed
processing cost per display).


There are also other pitfalls. If the display rate drops below 1-2 updates
per second, you might be incurring extra cost for what we call a "blocked
request". This is basically a issue with the data caching prediction system
because of the number of parameters. The next time you run in "real time",
please open the Performance Window and look at the "Blocked Requests"
number. Is it growing? If so, this is another reason for some speed loss.

At this point in time, I think my only suggestion is to stick with the
AlphaTable for a massive number of parameters. Looks like you already
figured this out on your own ;) If you want to use individual ActiveX text
displays, try and limit the number of simultaneous displays (as mentioned
earlier). Try splitting them into "N" tabs on the DisplayFolder.

Any comments?
Jim

[James Bretz]

Hi Wolfgang,

Brenda and I have discussed the issue one last time. We're pretty sure it
breaks down to these two items:

> 5) The ActiveX text object is much more complex than the AlphaTable. It
> has
> an entirely different interface in order to get data into the display
> (i.e.
> via the Microsoft Dispatch property interface). The data is actually being
> "pushed" from the outside into each individual property. This interface is
> a
> lot more flexible because each minute detail of the Text object can be
> driven with data/dynamics, but take a lot more processing power. The
> AlphaTable pulls the data directly from our data interface (parameter) and
> draws it directly to the screen (a lot quicker but less flexible).
>
> 6) The AlphaTable can contain many displays within it's boundary. In your
> example, you have 100 text objects in 16 AlphaTables. Compare this to 1400
> individual ActiveX displays. In essence, we only have 16 displays with 100
> parameters attached. If you had 1400 AlphaNumeric displays, I would
> imagine
> the rate would be closer to the ActiveX example. Again, the total number
> of
> simultaneous displays on the screen does dictate the processing
> requirements. Each display must be processed on the screen every update
> cycle. The more displays, the more time it will take (there is a fixed
> processing cost per display).

As you've proved, the system can comfortably process 1600 parameters as
evident by the AlphaTable example window. The data processing doesn't seem
to be the deciding factor. This is inline with my previous 15,000+ parameter
comment.

The main performance factor here can be attributed to the ActiveX property
interface and the sheer number of individual displays on the AnalysisWindow.
In fact, I can't even create 1400 AlphaTables on one AW without running out
of windows resources.

We will add this issue to our database to see if we can improve upon the
update speed somehow. Until then, stick with the AphaTables or attempt to
limit the number of ActiveX text objects visible at one time via the
DisplayFolder.

I hope this helps. Let us know if you have anything further,
Jim

[Mike Burt]

Hello Wolfgang:

I may be misunderstanding your overall goal here but there is possibly
another alternative to improve performance...would the Event Monitor
display possibly meet the requirements of what you are attempting to
display/present? Please review the description on the setup and usage
in the help system. With the Event Monitor you could import bulk
character sets and their correspondence to the derived equation
results via a text file as described in the help system. This would
alter the structure of what you have built up to this point but in the
long run would be able to handle future growth and be more flexible in
switching out character sets and/or their triggering conditions.

Just a thought...

[Wolfgang]

Hi Brenda, Jim and Mike

thank you for your helpful feedback.

I want to give you an impression of one of the analysis windows that
our engineers use.
To do this, I did a screen copy and removed all meaningful text infos
(see file "Wolfgang_many_text_objects_impression.gif").
Every color rectangle in this picture is a text object with text,
background color,
foreground color, visibiliy and sometimes border width dynamics driven
by
derived parameter values. The engineers cannot split it up the display
into less cramped screens
because the other computer monitors are similar cramped.

Conclusion - how to speed up a cramped display:

- Reduce the number of display objects
- Set the update rate of the individual display objects other than 0
- !! Use Display Folders - hidden Tabs don't eat CPU time !!
- avoid Blocked Requests
- Text Objects only update if one of the input values changes - try to
keep
the input values unchanging (e.g. reduce 4.2 to 4, 4.3 to 4, ...)

I think the derived parameters can also be a problem.
Maybe you can tell me more. This is how I understand the system:

- a derived parameter is calculated with the same update rate
as the fastest TPP parameter that is used in his equation.
- a derived parameter that is using a TPP parameter with no update
rate (0)
is calculated with ????? update rate.
(the update rate that I put into the default parameter table is
always changed to 0 by IADS).
- a derived parameter is only calculated if another derived parameter
is
using it or if any display object ist using it.
- a derived parameter that is used by 200 other derived parameters is
is
calculated every time when one of the 200 other parameters is
using it ????
- a derived parameter that is used by 200 display objects (e.g. to
drive
visibility) is calculated every time when one of the 200 display
objects is
using it ?????
- a derived parameter is calculated at the client.
- an IAP parameter is calculated at the IAP server (default: CDS
machine,
but can be any computer with IADS))
- an IAP parameter is calculated with the same update rate as the
fastest
TPP parameter that is used in his equation. It doesent matter how
many
derived parameter or display objects use it.
- an IAP parameter is calculated even if nothing is using it.

Especially the update rate 0 for the derived that is using the
asycronous TPP
may be something to explain. Is it calculatd every time when the
asyncronous
TPP value arrives at the CDS? In other words: parameter driven instead
of time driven?

Mike - I tired the Event Monitor and I think it cannot be used for our
purpose.

[Wolfgang]

Hi Brenda, Jim and Mike

Thank you for your helpful feedback.

I want to give you an impression of one of the
analysis windows that our engineers use.
To do this, I did a screen copy and removed all

meaningful text info’s (see file
"Wolfgang_many_text_objects_impression.gif").
Most colour rectangles in this picture are text objects
with text, background colour, foreground colour,
visibility and sometimes border width driven by
derived parameter values. Te engineers cannot split the
display up into smaller screens because the other

computer monitors are similar cramped.

Roundup of all hints "how to speed up a cramped display":

- Reduce the number of display objects
- Set the update rate of the individual display objects other than 0

- Use Display Folders - hidden Tabs don't eat CPU time
- avoid Blocked Requests
- Text Objects only update if one of the input values changes,
try to keep the input values unchanging (e.g. 4.2 -> 4.0, 4.3 ->
4.0,

)

I think the derived parameters can also be a problem.
Maybe you can tell me more. This is how I understand the system:

- A derived parameter is calculated with the same update rate

as the fastest TPP parameter that is used in his equation.

- A derived parameter that is using a TPP parameter with no update
rate (0)
is calculated with ??? update rate.
(The update rate that I put into the default parameter table for
this parameters is always

changed to 0 by IADS).

- A derived parameter is only calculated if another derived parameter
is using it
or if any display object is using it.
- A derived parameter that is used by 200 other derived parameters

is calculated every time when one of the 200 other parameters is

using it. ???
- A derived parameter that is used by 200 display objects (e.g. to

drive visibility)
is calculated every time when one of the 200 display objects is

using it. ???
- An IAP parameter is calculated with the same update rate as the

fastest
TPP parameter that is used in his equation.

It doesn’t matter how many derived parameter or display objects
use it.
- An IAP parameter is calculated even if nothing is using it. It
creates a data file
like a TPP parameter.

The hints for "how to speed up a cramped display"
can be supplemented for derived parameters:

- Use an IAP parameter if this parameter is used by many
other parameters or display objects.
- Write your own derived function if you have to handle
many input parameters to create a set of many output parameters.
- Assign a dedicated computer to be the IAP server (if the CDS is in
trouble)

[James Bretz]

Actually, from the picture Wolfgang recently uploaded, looks like he's
trying to output the entire PCM frame into one AnalysisWindow. It
makes sense from a debug standpoint, and in fact, we actually
developed a specific display (similar to the alpha table), to display
the PCM frame output. Although, the problem with the display is the
same as the alpha table. It's inflexible (unlike the individual text
objects).

Wolfgang. Is there anyway you can export that AnalysisWindow and email
it to me? I'll do my best for the next release and see if I can
optimize the ActiveX interface. Maybe we can get it running
satisfactorily. If not, at least this will help us to modify our PCM
frame display in order to get a similar output.

Jim

[James Bretz]

> another alternative to improve performance...would the Event Monitor
> display possibly meet the requirements of what you are attempting to
> display/present? Please review the description on the setup and usage

Ooops.. Also forgot to mention that he has 6.1. I don't think the
EventMonitor was released until 6.2.

It's very close to the ICAW display but more flexible and general, so
you can read up on the ICAW in your 6.1 help file to get a rough idea.
Let us know if you want us to send you documentation on this new
display.

Jim

[James Bretz]

Hi Wolfgang,

Let me respond to each one of your comments.

> I want to give you an impression of one of the
> analysis windows that our engineers use.
> To do this, I did a screen copy and removed all
> meaningful text info’s (see file
> "Wolfgang_many_text_objects_impression.gif").
> Most colour rectangles in this picture are text objects
> with text, background colour, foreground colour,
> visibility and sometimes border width driven by
> derived parameter values. Te engineers cannot split the
> display up into smaller screens because the other
> computer monitors are similar cramped.

Thanx for the pic. Yes, this is a very busy screen.

> Roundup of all hints "how to speed up a cramped display":
>
> - Reduce the number of display objects
> - Set the update rate of the individual display objects other than 0
> - Use Display Folders - hidden Tabs don't eat CPU time
> - avoid Blocked Requests
> - Text Objects only update if one of the input values changes,
>     try to keep the input values unchanging (e.g. 4.2 -> 4.0,  4.3 ->
> 4.0,

Actually, yes all true until the last point. It actually compares the
raw parameter value to detect a change, so changing the display format
to prevent a change in "text content" won't help. It would be a good
optimization though. I will add that to the list.

> I think the derived parameters can also be a problem.
> Maybe you can tell me more. This is how I understand the system:
>
> - A derived parameter is calculated with the same update rate
>    as the fastest TPP parameter that is used in his equation.

True, by default.... but, you can override this behavior by using the
"SetEquationUpdateRate" function as follows:

SetEquationUpdateRate( 2 ), A + B * C

This will force the equation to update at 2 samples per second. Make
sense?

> - A derived parameter that is using a TPP parameter with no update
> rate (0)
>    is calculated with ??? update rate.

Basically, you're talking about an "aperiodic" parameter. In this
case, if you mix Aperiodic parameter (SR=0) and periodic parameter
(SR>0) then the equation will get calculated at the rate of the
highest periodic parameter (again, by default unless you override via
SetEquationUpdateRate function.

If all the parameters in the equation are aperiodic (SR=0) then the
engine uses the first parameter it encounters as the "trigger"
parameter. This default behavior can be overridden via the
"SetTriggerParam" function:

SetTriggerParam( C ), A + B * C

I'm not sure if this is available in 6.1. There has been quite a few
upgrades and bug fixes to the "all aperiodic" derived equation, so if
you are using these types of equations, I recommend that you upgrade
to the latest version of Iads (6.6 coming soon).

>    (The update rate that I put into the default parameter table for
> this parameters is always
>      changed to 0 by IADS).

This means that the update rate is defined in the data source as
aperiodic (SR=0). During the startup procedure, the CDS will overwrite
the UpdateRate column for all parameters of type "Tpp" with what is
defined in the data source. If you disagree with what it is doing (and
you think the parameter is not aperiodic), we might have to discuss
this further with Mike Burt.

You can actually "override" this rate as well by putting:

rate=X (where X is any floating point number >= 0.0)

In the "DataSourceArgument" field of the ParameterDefaults table for
that given parameter. If you need more specifics, let me know.

> - A derived parameter is only calculated if another derived parameter
> is using it
>     or if any display object is using it.

Correct... and only is the display is actually updating. If it's
hidden (i.e. on a non-visible tab) then it's not being calculated.

> - A derived parameter that is used by 200 other derived parameters
>     is calculated every time when one of the 200 other parameters is
> using it. ???

Yes, true... but not in all cases. We try to "share" as many
parameters as possible, but as a general statement, this is true. In
most cases, this is not a performance issue, but it could potentially
be a performance issue if you have extremely complex layers of derived
equations.

One test is to simply put all the parameters into an AlphaTable (as
you did with your test) and then examine the update rate of the
screen. That will give you a good idea if the performance issues are
due to the equations, or simply the displays (as in our ActiveX vs
AlphaTable comparison).

> - A derived parameter that is used by 200 display objects (e.g. to
> drive visibility)
>     is calculated every time when one of the 200 display objects is
> using it. ???

Yes, true. Each display has it's own unique parameter "copy" (so it's
recalculated), *but* if the same parameter is used in 10 different
properties in the same display, it is shared (so calculated only
once). Does that make sense?

If parameter A is used in Visibilty, BackGroundColor, FillStyle in a
Text object, it shares 1 copy of A and thus is calculated only once.

> - An IAP parameter is calculated with the same update rate as the
> fastest
>     TPP parameter that is used in his equation.
> It doesn’t matter how many derived parameter or display objects
> use it.

Yes, same rules as explained above. The default behavior is to
calculate at the highest update rate of any input parameter, but you
can override that behavior.

The IAP equation rules and the normal derived are exactly the same.
The only difference is that it get's calculated in the IAP server and
sends it's results to the CDS (thus you will get a data file for that
parameter just like a Tpp parameter). For the full explanation, see
this post:

http://groups.google.com/group/iads/browse_thread/thread/3a073c6f84012fb0

> - An IAP parameter is calculated even if nothing is using it. It
> creates a data file
>     like a TPP parameter.

Yes, exactly. Again, see the link for further explanation.

> The hints for "how to speed up a cramped display"
> can be supplemented for derived parameters:
>
> - Use an IAP parameter if this parameter is used by many
>    other parameters or display objects.

Yes, but you need to determine first if the derived calculation is the
root of the performance issue. Most of the time it isn't, but it's
possible if your equations are very complex.

You can certainly test this technique and see if it increases the
display rate, but please do read the link above for advantages and
disadvantages first.

> - Write your own derived function if you have to handle
>    many input parameters to create a set of many output parameters.

Yes true, but the "many inputs many outputs" function is a very tricky
function to write. We're working on a new derived function interface
to make this easier in the future. Let me know if you need more info
on this subject.

> - Assign a dedicated computer to be the IAP server (if the CDS is in
> trouble)

Yes, true


Hope this helps,
Jim