Проверка скорости обработки, --данных-- Опции

[Fors1k]

Тест не совсем корректен.

Не совсем корректен относительно чего?
Тест проводился для проверки фразы:

Если уж речь идет о скорости, то не используйте глобальные переменные, доступ к локальным быстрее.

Мы замерили 300 раз по 20млн обращений к локальной, и столько же к глобальной. Эксперимент выявил, что ситуация обратная, так что тест считаю корректным. Отмечу, что таким высказыванием забит весь интернет, так что здесь вопросы не к cirus, а к тому, кто это придумал))

Код

--lua
a = 0
local b = 1

Где лежит b ? Почему в разных, если область памяти пока только одна - глобальная.

Нет, здесь уже две области памяти. Следует отличать область памяти, и область видимости. Область памяти - полка в шкафу. Область видимости - разрешение заглянуть на ту или иную полку. В этом коде a и b лежат на разных полках, но дальше по коду любой будет иметь право лазить хоть на одну, хоть на другую. А теперь вопрос: стоит ли тогда просить систему строить две полки, если у всех доступ будет к обоим? Посмотрим, как это выглядит в коде:

Код

--lua
a = 5
local b = 7
log(_G.a) -- 5
log(_G.b) -- nil

Глобальные переменные хранятся в таблице _G. Как мы видим, переменная b, хоть и находится в той же области видимости, но в таблице _G ее нет. Где же она? Где-то в недрах памяти lua. Без специальных библиотек посмотреть где они лежат - невозможно, но суть в том, что не в _G. В итоге, кроме того, что мы заставили систему зачем-то строить отдельную полку для хранения b, мы ничего не добились написав перед ней local.

Сообщение отредактировал Fors1k - 11.6.2020, 18:12

[Levo222]

Тест проводился для проверки фразы:

Надо проводить тест не для проверки этой фразы а чтобы решить конкретную задачу)
Я тоже сталкивался с этой фразой, только там обрабатывалась пара десятков функций через string.match и подфункции табличных значений и кучу разных других опций, у нас всё просто, так вот может и будет разница
пока что у меня картиночка не работает что

Код

local G = color (100, 100, h) --не считается данными цвета а только значением переменной
а G == 0 --не возвращает значения цвета...

[Madeus]

Что-то мне подсказывает что результаты не совсем корректны, и больше похожи на погрешность. У меня как-то так, и по всей видимости сильно зависят от железа.

Код

18:43:20 3 (, 0): Global Var: 1.811 секунд
18:43:20 3 (, 0):  
18:43:26 3 (, 0): Loacal Var: 1.811 секунд

Код

18:44:46 4 (, 0): Global Var: 0.01811 секунд
18:44:46 4 (, 0):  
18:44:52 4 (, 0): Loacal Var: 0.01810 секунд
18:44:52 4 (, 0): 4
18:44:52 4 (, 0): nil

[Cockney]

Не совсем корректен относительно чего?
Тест проводился для проверки фразы:
Мы замерили 300 раз по 20млн обращений к локальной, и столько же к глобальной. Эксперимент выявил, что ситуация обратная, так что тест считаю корректным. Отмечу, что таким высказыванием забит весь интернет, так что здесь вопросы не к cirus, а к тому, кто это придумал))

Дело не в количестве обращений. А во времени обращения к какой-то переменной, когда область памяти содержит большой объем таких переменных. Как я и приводил пример, пусть в тесте будет 10000 глобальных переменных вида:

Код

a_1 = 0
...
a_1000 = 0

а сам тест выглядит примерно так:

Код

--lua
//в глобальном контексте

a_1 = 0
a_2 = 0
a_3 = 0
a_4 = 0
//.....

t = os.clock()
a_4 = 100
timeElapsed = os.clock() - t

function f()
   //в локальном контексте
   local a_1 = 0
   local a_2 = 0
   local t = os.clock()
   a_2 = 100
   local timeElapsed = os.clock() - t
end

[Fors1k]

больше похожи на погрешность.

Да, я тоже к этому склоняюсь. Если увеличивать количечство замеров, количество различных пк, на которых проводим тесты и т.д. ,то наверное мы получим примерно одинаковый результат.

вот еще несколько замеров сделал

Global Var: 0.02728 секунд
Loacal Var: 0.02899 секунд

Global Var: 0.02856 секунд
Loacal Var: 0.02848 секунд

Global Var: 0.02667 секунд
Loacal Var: 0.02888 секунд

Практически одинаковые результаты, но global почему-то у меня все равно чуть быстрее..

Сообщение отредактировал Fors1k - 11.6.2020, 19:06

[Cockney]

Нет, здесь уже две области памяти. Следует отличать область памяти, и область видимости. Область памяти - полка в шкафу. Область видимости - разрешение заглянуть на ту или иную полку. В этом коде a и b лежат на разных полках, но дальше по коду любой будет иметь право лазить хоть на одну, хоть на другую. А теперь вопрос: стоит ли тогда просить систему строить две полки, если у всех доступ будет к обоим?

Да, моя ошибка. Сам опроверг себя, приведя ссылку на документацию.

--lua
a = 0 // глобально для всех скриптов
local b = 0// глобально только для текущего

[Levo222]

Практически одинаковые результаты, но global почему-то у меня все равно чуть быстрее..

А у меня медленнее. Может дело в установленных у тебя множестве патчей? Один из которых меняет состояние некоторых переменных с глобальных на локальные вне скрипта?

[Fors1k]

Не знаю, что за патчи, у меня самый обычный пилот)

А у меня медленнее.

Ну вот. У меня быстрее, у тебя медленнее, у Madeus одинаково. Итог: разницы в скорости нет.

Сообщение отредактировал Fors1k - 11.6.2020, 19:29

[Levo222]

Не знаю, что за патчи, у меня самый обычный пилот)

Ну вот. У меня быстрее, у тебя медленнее, у Madeus одинаково. Итог: разницы в скорости нет.

У меня то есть, значит проблема в конфигурации системы/конкретного приложения/ обращении к ним/через него. Т.е. надо локально проблему решать, А мне это локализовать переменные за циклом содержащие проверку цвета внутри самого цикла.
Я так и не понял что быстрее - мы пока что без функций тут не сделали способа считать данные цвета из переменной, что хотелось бы увидеть

[cirus]

Я так и не понял что быстрее

Проводите нормальные тесты:

Дело не в количестве обращений. А во времени обращения к какой-то переменной, когда область памяти содержит большой объем таких переменных.

[Fors1k]

У меня то есть

Ну запустите еще раз, получите другой результат. Разницы в скорости нет. Вот, запустите этот код(6 тестов подряд), и покажите результат:

Исходный код

--lua
log"clear"log"mode compact"
for k=1,6 do
tAverage1=0
for c=1, 300 do
a=4
t = os.clock()
for i=1, 10000000 do
a=a*2
a=a/2
end
t1=(os.clock() - t)
tAverage1=tAverage1+t1
end
log ('Global Var: '..string.format("%.5f", tAverage1/300)..' секунд')

tAverage2=0
for c=1, 300 do
local b=4
t = os.clock()
for i=1, 10000000 do
b=b*2
b=b/2
end
t2=(os.clock() - t)
tAverage2=tAverage2+t2
end
log ('Loacal Var: '..string.format("%.5f", tAverage2/300)..' секунд')
log(" ")
end

Мой результат

Global Var: 0.02600 секунд
Loacal Var: 0.02505 секунд

Global Var: 0.02262 секунд
Loacal Var: 0.02427 секунд

Global Var: 0.02550 секунд
Loacal Var: 0.02381 секунд

Global Var: 0.02466 секунд
Loacal Var: 0.02512 секунд

Global Var: 0.02477 секунд
Loacal Var: 0.02512 секунд

Global Var: 0.02617 секунд
Loacal Var: 0.02521 секунд

Cчет 3:3

Сообщение отредактировал Fors1k - 11.6.2020, 19:48

[Levo222]

большой объем таких переменных.

Дак каких таких переменных? Этого я и пытаюсь добиться. Здесь уже и тесты по замерам глобальных провели и прочее. Но так и не привели никакого примера переменных содержащих значения функций colora например за циклом, чтобы не вызывало каких-либо трудностей

когда область памяти содержит большой объем

А формат этой области памяти какой должен быть? Вот я о чём и спрашиваю, что там в lua нагородили чтобы нормально всё работало, а то сталкиваюсь с лагами, и хз как решить

[Levo222]

Разницы в скорости нет. Вот, запустите этот код(6 тестов подряд), и покажите результат:

Код

Global Var: 0.02693 секунд
Loacal Var: 0.02682 секунд
 
Global Var: 0.02693 секунд
Loacal Var: 0.02688 секунд
 
Global Var: 0.02693 секунд
Loacal Var: 0.02688 секунд
 
Global Var: 0.02687 секунд
Loacal Var: 0.02693 секунд
 
Global Var: 0.02688 секунд
Loacal Var: 0.02693 секунд
 
Global Var: 0.02687 секунд
Loacal Var: 0.02688 секунд

Да ты высосал просто код из пальца, подтасовывая данные в нём для отклика данных результата.
Глобальный обгоняет локальный только под конец, я полагаю ввиду хранения каких-то данных по типу кэша из ранее вызывавшихся - это к конфигурации системы и области хранения глобальных данных в целом наверное относится. Но мы то говорим о коротких дистанциях. У меня нет времени разогревать скрипт чтобы он набирал кэш и потом нормально работал. То что тут требуется это максимальный отклик сразу.

Вот еще один тест:

Код

Global Var: 0.02682 секунд
Loacal Var: 0.02682 секунд
 
Global Var: 0.02687 секунд
Loacal Var: 0.02682 секунд
 
Global Var: 0.02682 секунд
Loacal Var: 0.02682 секунд
 
Global Var: 0.02682 секунд
Loacal Var: 0.02677 секунд
 
Global Var: 0.02682 секунд
Loacal Var: 0.02682 секунд
 
Global Var: 0.02682 секунд
Loacal Var: 0.02682 секунд
 

чисто посмеяться

Есть некая закономерность цикличности очерёдности обработки, которую по всей видимости не удалось обойти и разработчикам Lua, поскольку все их знания лежат в области времени
Эти разговоры все что и споры на тему курица или яйцо, хотя понятно же что яйцо потому что из него курица сначало из ящерицы крылья себе отращивала, а потом уже несла яйца в качестве курицы. Курица не считала себя таковой вначале) Её счёл такой человек - и записал, хотя становление её в качестве пернатого существа продолжается. Есть определённая культура создателей кода, которые наверно лучше знали как он должен выглядеть по их задумке, поэтому давайте будем придерживаться именно его, а дальше если их методы и рекомендации не подойдут, то можно в целом не использовать Lua а взять способ под конкретную цель, в которой метод не важен - Главное эффект.

[Madeus]

Результат

Код

Global Var: 0.01815 секунд
Loacal Var: 0.01810 секунд
 
Global Var: 0.01810 секунд
Loacal Var: 0.01810 секунд
 
Global Var: 0.01809 секунд
Loacal Var: 0.01811 секунд
 
Global Var: 0.01810 секунд
Loacal Var: 0.01812 секунд
 
Global Var: 0.01810 секунд
Loacal Var: 0.01814 секунд
 
Global Var: 0.01816 секунд
Loacal Var: 0.01816 секунд

[Fors1k]

Ну вот мы и убедились, что разницы в скорости нет)
То один, то другой обгоняет, что является погрешностью.

Madeus, благодарю за спойлер)

Сообщение отредактировал Fors1k - 11.6.2020, 20:17

[Levo222]

что является погрешностью.

Это не погрешность
погрешностью я называю когда ты трясущейся рукой выстрелил 5 раз в мишень и у тебя 20% результатов в молоко. Это погрешность. А когда берется в рассчёт время, то решает момент вывода данных: Т.е. когда тебе контрольный замер делают, а не когда ты выбил 10 из 10.
а

цикличности очерёдности обработки. Т.е. времени вывода

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

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

[Fors1k]

Это не погрешность
погрешностью я называю когда ты трясущейся рукой выстрелил 5 раз в мишень и у тебя 20% результатов в молоко. Это погрешность. А когда берется в рассчёт время, то решает момент вывода данных:
а

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

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

Даже не знаю, как это комментировать.
Вы, походу, не очень понимаете что написано в коде теста скорости)

[Madeus]

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

А по поводу скорости функций поиска цвета, уже объяснили, что это функции winapi и быстрее не получится.

[Levo222]

Даже не знаю, как это комментировать.

Да я написал уже что часть нагрузки обработки возможно берет на себя системыный кэш что и уравнивает результаты, хотя это тоже теория.
А в чём проблема использовать локальные данные и не пытаться опровергнуть то, чего не требуется?

локальная переменная перестает существовать,как только заканчивается

Вот! Главное использовать что-то, чтобы самому позже об неё не споткнуться, поэтому не надо ничего усложнять.

скорости функций поиска цвета, уже объяснили, что это функции winapi и быстрее не получится.

Я про Lua вообще спрашивал, Но тут примеров замеров за циклом и "в" так и не привели, кроме нагораживания глобальных функций. Поэтому ждём решения.

[Fors1k]

"Более того, доступ к локальной переменной быстрее, чем к глобальной."

Здесь мы убедились, что это не так.

"Локальные переменные помогают вам избежать засорения глобального окружения ненужными именами. И наконец, локальная переменная перестает существовать,как только заканчивается ее область видимости, позволяя сборщику мусора освободить память, занимаемую ее значением."

Это все логично, и очевидно, только если у нас код не 10 строк, в котором всего одна область видимости.

"Хороший стиль программирования заключается в применении локальных переменных везде, где это возможно."

Естественно. Вот тут, конечно, создатели lua странные ребята. В других языках переменные всегда автоматически являются локальными, что бы не было как в луа, где модификатор local занимает кода как сама бизнес-логика.

не пытаться опровергнуть то, чего не требуется?

Кому не требуется? Было предположение о том, что доступ к локальным переменным быстрее, чем к глобальным. Мне стало интересно, и я проверил это тестом. Не понимаю, о чем вы.

А в чём проблема использовать локальные данные

Вам уже объяснили, что если в наивысшей области видимости написать local, то данные все равно будут глобальными:

--lua
a = 0 // глобально для всех скриптов
local b = 0// глобально только для текущего