DroidScript
DroidScript
инструменты для мобильной разработки

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

Базовый курс программирования на Thunkable X  
04.01.2020

Вопросы быстродействия и оптимизации обычно выносят за рамки основ, но применительно к Thunkable X об этой проблеме должен знать каждый пользователь. Возможно, Thunkable X не является чемпионом по эффективности оптимизации блоков, но, если ничего не подозревающий разработчик будет руководствоваться официальной документацией, то с вероятностью 100% некоторые его блоки будут работать в несколько тысяч раз медленнее тех блоков, которые на самом деле нужно использовать. Какой С++ и многопоточность? Вы о чём? Всего-то и нужно вместо одного блока использовать другой! Это не превратит бобра в гепарда, но позволит точнее очертить границы возможного использования мобильных приложений на Thunkable X

На первый взгляд кажется то, что ничего в блоках переменных нет, но это не так. Помните, как на первом занятии прозвучала рекомендация не использовать блоки глобальных переменных, потому что они не во всех ситуация работают стабильно, загрязняют пространство имён и могут очень сильно замедлить работу в редакторе блоков? Существует и ещё одна причина – невозможно медленная скорость их работы.

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

Функция для оценки производительности

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

Время работы показанного цикла составляет примерно 0.881 секунды. Если блок “app LoopCount” заменить на блок переменной функции, то выполнение цикла с 1000 итераций составит 0.013 секунды – в тысячу раз быстрее! Метод LocalDB.setCell выполняется в 10 раз быстрее и является неплохой альтернативой.

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

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

  set x to = 10					- 0.001
  
set stored to = 10 – 0.889 set app to = 10 – 1.271
set cloud to = 10 – 3..10

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

  Button.setWidth = 100				– 4.999

  Alert.setTitle				– 5.108
Label.setText = "Hello" – 6.060

Запись значений свойств работает очень медленно

  x = Label.getText				– 0.044
x = Button.getWidth – 0.038

Получение значений свойств происходит в 100 раз быстрее записи свойств

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

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

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

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

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

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

  x = List.get (10 тыс. итер.)			– 0.063
x = LocalDB.getCell (10 тыс. итер.) – 0.362 x = Object.getProperties (10 тыс. итер.) – 2.129

Получение значения свойства объекта происходит достаточно медленно.

  х = 10 + 3					– 0.002
join "Hello" и "world" – 0.002
If < i = true – 0.001
Create object – 0.001
do something – 0.029
Clone Label – 6.766 Create Row – 8.576
Create Label – 10.594
Create Switch – 11.578
Create Slider – 11.9752 Create Image – 12.479
Create Text Input – 14.920
Create Column – 17.181 Create Button – 22.051

100 кнопок содаются за 22 секунды - это просто ужас!

  repeat с индексом (10 тыс. итер.)		- 0.038
repeat while с индексом (10 тыс. итер.) - 0.052
count width (10 тыс. итер.) - 0.029
for each item (10 тыс. итер.) - 0.074 forever (10 тыс. итер.) - 18.217

Цикл по списку является самым медленным. Если цикл while использует счётчик, то он медленнее count width. Мне непонятна причина создания блока бесконечного цикла forever, который работает в 250 раз медленнее бесконечного цикла на базе count width.

  add polyline (Map canvas)	- 18.129

  draw line from			- 0.574

За 1 секунду холст позволяет вывести всего 170 линий. Холст есть - графики нет. Возможности холста ограничиваются черепашьей графикой и спрайтовой анимацией с рывками. Map canvas также можно использовать в качестве холста, но этот вариант работает также медленно, как и создание кнопок.

После исправления серьёзного бага, связанного с версией 120 Live, производительность блоков упала на 30-100%. Разработчики провели изменения в целях ускорения работы блоков, но это привело к их ещё более медленной работе.

Для обновления 100 глобальных app-переменных требуется 1 секунда! Это очень медленно!

Для изменения надписи всего на 50 кнопках требуется 9.5 секунд!

Хорошо, но на iOS-то всё это будет работать быстрее?! Да, на iPhone6 всё работает примерно в 2.5 раза быстрее, но это никак не решает проблему, так как список всего из 10 строк с тремя текстовыми полями и одной пиктограммой в каждой строке даже на iPhone6 будет отображаться 2 секунды! Сколько времени занимает создание 100 кнопок на JavaScript в WebViewer? 9 миллисекунд. 100 "нативных" кнопок за 22 секунды или 100 web-кнопок за 9 миллисекунд?

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

Исправить ситуацию с производительностью можно двумя способами - либо переделать ядро Thunkable X, что делать никто не собирается, либо добавить в Web Viewer полноценную поддержку web-технологий, что также маловероятно из-за отношения к этому компоненту Apple.

Базовый курс программирования на Thunkable X  
© 2016-2020  Александр Страшко