Быстродействие

Вопросы быстродействия и оптимизации обычно выносят за рамки основ, но применительно к Thunkable X данный вопрос нужно держать на контроле, так как одни блоки выполняются достаточно быстро а другие - крайне медленно.

Соберём испытательный стенд в виде следующего блока.

Тестирование происходило на Android 8.1 (MTK6739WA, 4 ядра, 1.3 ГГц).

После нескольких обновлений платформы производительность блоков улучшилась. Результаты теста на 04.01.2020 и 23.05.2020 (в скобках).

Внимание: через некоторое время после выпуска обновлений выяснилась крайне неприятная вещь: увеличения скорости выполнения блоков привело к резкому падению стабильности их работы. Выражается это в том, что блоки просто не работают, если они используются в каком-то процессе быстрого обновления данных, например, два блока идут друг за другом и последующему блоку требуются данные из блока перед нм. В качестве обходиного решения необходимо использовать блоки задержки для того, чтобы система получила дополнительное время для завершения выполнения текущего блока.

Скорость выполнения 100 итераций (если не указано другое значение) в секундах:

  set x to = 10					- 0.001 (0.001)
  
  set stored to = 10				– 0.889  (0.668)

  set app to = 10				– 1.271 (0.002)

  set cloud to = 10				– 3..10 (0.378)

  change by (app value) (1 тыс. итер.)		– (0.11)

  change by (stored value) (1 тыс. итер.)	– (5.795)

  change by (cloud value) (1 тыс. итер.)	– (слишком долго)

  change by (x) (1 тыс. итер.)			– (0.005)

При использовании cloud происходит обращение к Firebase

  Button.setWidth = 100				– 4.999 (0.12)

  Alert.setTitle				– 5.108 (0.028)

  Label.setText = "Hello"			– 6.060 (0.129)

  x = Label.getText				– 0.044 (0.117)

  x = Button.getWidth				– 0.038 (0.13)

  List.insert at last (10 тыс. итер.)		– 1.422 (0.621) 

  Object.setProperty (10 тыс. итер.)		– 1.459 (0.054)

  List.setCell (10 тыс. итер.)			– 1.739 (0.053)

  LocalDB.setCell (10 тыс. итер.)		– 5.487 (4.85)

Локальная таблица записывает свойства достаточно медленно

  x = y (10 тыс. итер.)				– 0.042 (0.049)

  x = List.get (10 тыс. итер.)			– 0.063 (0.064)

  x = LocalDB.getCell (10 тыс. итер.)		– 0.362 (0.497)

  x = Object.getProperties (10 тыс. итер.)	– 2.129 (0.067)
 

  х = 10 + 3					– 0.002 (0.001)

  join "Hello" и "world"			– 0.002 (0.002)

  If < i = true 				– 0.001 (0.001)

  Create object 				– 0.001 (0.001)

  do something					– 0.029 (0.083)

  Clone Label 					– 6.766 (2.981)
  
  Add Marker 					– (12.061)

Вывод маркеров на карту - это одна из самых медленных операций

  Create Row 					– 8.576 (4.685)

  Create Label 					– 10.594 (2.399)

  Create Switch 				– 11.578 (2.003)

  Create Slider 				– 11.9752 (2.419)

  Create Image 					– 12.479 (2.4040)
  
  Create Text Input 				– 14.920 (2.632)

  Create Column 				– 17.181 (2.681)

  Create Button 				– 22.051 (2.81)
  
  All button in Row 				– (0.028)
  

  repeat с индексом (10 тыс. итер.)		- 0.038 (0.044)

  count width (10 тыс. итер.)			- 0.029 (0.049)

  draw line					- (0.594)

Последнее обновление Thunkable X говорит о том, что разработчики cущественно увеличили производительность блоков. Однако, не будем спешить с выводами. Глобальные переменные стали работать ощутимо быстрее, но на одной тысяче итераций блок инкремента глобальной переменной app происходит в 22 раза медленнее инкремента переменной из параметра функции.

Скорость создания 100 кнопок увеличилась в 10 раз, но, для справки, 100 кнопок на JavaScript в WebViewer создаётся за 9 миллисекунд. 100 "нативных" кнопок за 2 секунды или 100 web-кнопок за 9 миллисекунд? К тому же, блоки для работы со спрайтами и графикой всё ещё работают очень медленно. За 1 секунду выводится всего 200 линий - это катастрофа!

Хочу обратить ваше внимание на то, что при помощи данного теста происходит измерение скорости выполнения блоков, и не учитывается скорость отображения данных на экране. К сожалению, графическая подсистема Thuinkable X работает невозможно медленно и, если к этому добавить ещё и анимации элементов интерфейса, то несложно понять, что в реальных приложениях всё будет работать намного медленнее по сравнению с тем, что показано в данном тесте. Например, если в цикле от 1 до 5 происходит вызов всего одной функции, то это может увеличить время работы цикла в 10-15 раз по сравнению с тем случаем, когда блок вызова функции заменён на все блоки из этой функции.