Themes Drastically slowing down Screen/Component Generation

Bugs
1

What do you want to achieve?

Faster Screen/Component Generation while using Themes. Currently the generated code is ridiculously slow and fully building my system is taking over 100 minutes. Once generated, the theme swapping works great, but it is an unacceptable time sync to get to that point.

What have you tried so far?

Upgraded from SL 1.3.4 to SL 1.4.0

Speed Comparison

Screen 1.3.4 (ms) 1.4.0 (ms)
1 174 839
2 15 9608
3 206 50,934
4 1,428 301,029

Benchmark made using exact same system code, from 1.4.0, then replacing ‘ui_object_set_themeable_style_property’ lines with the direct assignments as 1.3.4 would have generated

Others

  • SquareLine Studio version: 1.4.0

This appears to apply to widgets/components generated directly in Squareline as well as widgets/components generated in code.

For every widget using a theme made (each ui_object_set_local_style_property call), the next widget made that has a theme takes longer. This has resulted in order of screen creation drastically increasing generation times and full system generations to take time measured in hours, when previously it would only be ~10 seconds.

When i stress tested by just creating a huge number of components using themes, i was able to watch the time per cycle drastically increase.
Each pass of ui_object_set_local_style_property took:

Pass Time (ms)
1 10
100 20
200 35
300 45
400 70
600 100
800 125
1000 150
1500 200
2000 250

As it went, it would just take longer for each one

2

Thanks for the feedback. It would be nice if you give the platform where this drastic slowdown happens, because for example on a PC or a Raspberry Pi there are no noticeable slowdowns. I think in this case it’s related to dynamic memory reallocation when the theme style-property settings are registered for the widgets (into a 2-dimensional dynamic array). Some platforms make memory allocation in clever ways, some (your case) probably always move the whole array to an empty area/heap every time a new element is added. (Maybe LV_MEM_CUSTOM or other settings have an impact on this allocation/preallocation behaviour. We’re working on a solution, like occupying the area for the array in advance, or maybe we’ll switch to linked lists instead which take some more memory but will be faster on machines that have slower memory operations. And we’ll possibly make theme-handler code selectable if there are global colors in a project but there’s only a single default theme, that is, when no theme-handling is required.)

3

Chip: STM32F7
Mode: Direct
Using Dual Frame Buffers

Potential Notes:
Heap is External

Thank you for reviewing our issue.

We have a solution that will meet our current needs and will keep an eye out for how the theme management changes in future updates.

1 Like