Found in discussion here:
If you are struggling with AlarmHistory performance in mappView, especially with larger alarm histories, here are a few things we found that may help improve performance.
Thanks @PatrickS
My two cents to this topic:
- We also had troubles with AlarmHistory-Performance in the past (and are still not happy).
We decided to not increase the available memory for the AlarmHistory, but leave it at the default 512KB (results in aroud 1000 Alarms for us). - In the past, filtering didn’t improve performance for us.
The widget has to load the whole Alarm-History and filters after the fact. So you only filter from an already loaded list. - This likely doesn’t apply to you, as you are using AS6:
There is an option “Auto detect” unter the Alarm Text Snippets category in the/every AlarmXCore (AS4 / mappServcies 5.x - can be found in the AlarmXList-Files in AS6).
By setting it toEnabledyou are storing only the necessary snippets for an alarm, thus reducing the memory a single alarm - The performance of the client makes adifference.
How does your client compare to opening the history with e.g. your laptop?
A few insights on how the AlarmHistory-Module stores the alarms:
- The complete history is saved in the datamodule/-object AlarmX$0
- The module is organized in blocks of 256Bytes. Every alarm takes up as many slots as it needs to store all information (Timsetamp, AlarmID, Message, Additional Info, Snippets etc.)
- If a single alarm takes up e.g. 300Bytes it uses two whole slots. The next alarm can only start at the beginning of the next slot.
- AutoDetect does the following:
If it is Disabled, every alarm contains all(!) snippets defined in the alarmCore/List. So if you define for example 20 alarms and 20 snippets (1 for each alarm), every entry of a single alarm also contains all 20 snippets.
With AutoDetect enabled, only the snippets for this alarm are saved.
This research is based on mappServices 5.24., so I am not quite sure what exactly changed for mappServices 6.x. I assume it works very simmilar.
I explain that in detail, to give a better understanding on how thje configured memory is used so you can better decide, what you need.
For comparison here is a raw-dump of a single alarm in the history (left: auto detect off, right: auto detect on)
To conclude:
- Depending on where the biggest bottleneck is:
Maybe it is worth trying to look in the Cycle Idle Time. In the past we were able to increase performance a little bit by adjusting it. - Maybe it is worth trying to reduce the available memory, if you are fine with a shorter history.
- Maybe you can shorten text-references to increase the number of stored alarms and then reduce the amount of memory for the module.
- @B&R
: Hopefully the system gets a performance-boost in the future
A few Help-Links
- Alarm snippets
- Idle time → Maybe there is a better explanation somewhere?
- AlarmXHistory \ Optimization

