Как влияет кол-во неиспользуемых функций в файле индикатора

Страницы: 1
RSS
Как влияет кол-во неиспользуемых функций в файле индикатора
 
Господа, подскажите пожалуйста, как влияет на производительность или память компьютера наличие в файле индикатора неиспользуемых функций?
Например если открыто 20 графиков и на каждом такой индикатор? Будет от этого болше загрузка квика, или влияет только кол-во работающих функций?
Ну или например размер этого файла влияет на производительность квика?


Например их 20 но используется только 1 на данный момент.


function 1()
function 2() ...


function 20()
                       
 
Здравствуйте.

От количества используемых функций, переменных растёт потребление оперативной памяти. По сути, количество неиспользуемых переменных или функций не должно влиять на производительность работы скрипта или индикатора.

Однако по обращениям клиентов мы подозреваем, что в текущей реализации QLUA данная зависимость, к сожалению, присутствует, то есть, чем больше объявленных переменных, тем хуже       производительность. Данная проблема сейчас нами изучается.

Касательно Вашего вопроса. К сожалению, подобные "нагрузочные" тесты с индикаторами не проводились, поэтому предоставить какую-либо информацию по Вашему вопросу мы не можем.

Если Вы столкнётесь с проблемами производительности, используя индикаторы на графиках, просьба сообщить и предоставить подробное описание - будем изучать проблему.
 
На самом деле, количество используемых функций влияет на производительность.
Поясняю:
Если функции глобальные, то указатели на них помещаются в глобальную таблицу , что увеличивает ее размер и соответственно поиск по ней требуемой функции.
Если функция локальная, то она увеличивает локальную таблицу и аналогично выше сказанному
если применить предварительную выборку функции, то это требует добавку кода, что влияет на производительность.
-----------------
Таким образом, в общем случае количество функций влияет на производительность.
 
предположу, что такое влияние может наблюдаться во всех системах, использующих виртуальные машины (это гипотеза).  
 
но скорее всего это влияние практически незаметно.
Большее влияние это оказывает на общее число функций особенно локальных.
 
Цитата
nikolz написал:
На самом деле, количество используемых функций влияет на производительность.
Поясняю:
Если функции глобальные, то указатели на них помещаются в глобальную таблицу , что увеличивает ее размер и соответственно поиск по ней требуемой функции.
Если функция локальная, то она увеличивает локальную таблицу и аналогично выше сказанному
если применить предварительную выборку функции, то это требует добавку кода, что влияет на производительность.
-----------------
Таким образом, в общем случае количество функций влияет на производительность.
размер таблицы в луа-реализации практически не влияет на скорость выборки информации из нее, так как используется механизм хеширования ключей.

для таблиц с целочисленными индексами вообще не влияет.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
Цитата
s_mike@rambler.ru написал:
Цитата
nikolz написал:
На самом деле, количество используемых функций влияет на производительность.
Поясняю:
Если функции глобальные, то указатели на них помещаются в глобальную таблицу , что увеличивает ее размер и соответственно поиск по ней требуемой функции.
Если функция локальная, то она увеличивает локальную таблицу и аналогично выше сказанному
если применить предварительную выборку функции, то это требует добавку кода, что влияет на производительность.
-----------------
Таким образом, в общем случае количество функций влияет на производительность.
размер таблицы в луа-реализации практически не влияет на скорость выборки информации из нее, так как используется механизм хеширования ключей.

для таблиц с целочисленными индексами вообще не влияет.
Ну если хотите подробно рассмотреть вопрос, то начните с момента
каким образом луа определит есть ли такой хеш или это новый?  
И ответьте влияет ли на это  число существующих функций.
 
например, есть глобальная функция с именем "start"
В скрипт грузится  и исполняется строка типа _G["start"]()
-------------------
Вопрос:
В каком случае эта строка исполнится быстрее
когда глобальных функций 1, или когда их 1000000.
 
поясняю:
Смотрим API вызов функций:
----------------------
lua_getglobal(L, "f"); /* вызываемая функция */ lua_pushliteral(L, "как"); /* 1-й аргумент */
-------------------
lua_getglobal(L, "t"); /* таблица для индексирования */
---------------------
итд
---------------------
Во всех случаях мы указываем имя функции и(или)  имена переменных как строки.
-------------------  
Смотрим  исходный код например LUA 5.3 (особой разници нет так как это у всех версий луа одинаково)
если хорошо искать,
то найдет функцию которая создаст кэш нашей строки и проверит новая это строка или нет
===============
TString *luaS_new (lua_State *L, const char *str) {
unsigned int i = point2uint(str) % STRCACHE_N; /* hash */
int j;
TString **p = G(L)->strcache[i];
for (j = 0; j < STRCACHE_M; j++) {
if (strcmp(str, getstr(p[j])) == 0)
return p[j];
}
for (j = STRCACHE_M - 1; j > 0; j--)
p[j] = p[j - 1];  p[0] = luaS_newlstr(L, str, strlen(str));
return p[0];
}
Не сложно увидеть в этой функции циклы по глобальной таблице.
Кроме того, второй цикл занимается перемещением элементов.
----------------------
Очевидно чем больше таблица и дальше по ней наша строка, тем дольше поиск.
------------------------
В итоге, по-моему мнению,
число функций, как и число переменных,
влияет не только на затраты памяти,
но и на производительность т е загрузку процессора.
-----------------
 
Я уже спрашивал, способна ли вся эта толпень придурков, кукарекающая про свои "огромные тыщи" хоть на одну сотую долю процента окучить весь этот бред в реальных программах? Лично я думаю, что в моём скрипте этих "глобальных переменных" больше, чем у них у всех, вместе взятых - примерно тысяч сто, может двести. Но надо быть полным дебилоидом, чтобы организовывать эти переменные в виде линейного массива когда под руками есть дерево. ДАЖЕ В ЭТОМ случае никаких проблем с производительностью быть не может! А если организовать данные НОРМАЛЬНЫМ образом, то доступ к этим элементам и подавно идёт со свистом. У меня сплошь и рядом операторы типа:
a[i][4][0][a[i][1][4][n]+1]=(a[i][4][0][s]*a[i][4][0][s+1]*a[i][0][8]-k)/a[i][4][0][s]/a[i][0][8];
И у меня не было пока что НИ МАЛЕЙШИХ претензий к производительности - разве что когда этот припадочный сборщик мусора взбесился. А на следующий день (я так и не дождался завершения работы и лёг спать - часа три он мурыжил тестовый массив) я включил комп и снова запустил этот тест с самого утра. Так он отмолотил файл с начала до конца ЗА ДВАДЦАТЬ СЕКУНД! Что он вытворяет - уму непостижимо!
 
В качестве совета начинающим.
---------------------------
В луа вызов функций самая тяжелая операция (в смысле затрат времени процессора).
---------------------
Поэтому, если очень хотите экономить время,
то вставляйте код функции там,
где хотите вызвать функцию.
--------------------
Безусловно это приведет к затратам памяти.
------------------------
На самом деле, все не так уж и страшно.
---------------------------
Если Вы начинающий,
то у Вас будут существенно большие затраты и памяти и времени
процессора из-за неоптимальности вашего алгоритма и выбираемых Вами методов.
 
 
nikolz,Начинающие на эту белиберду, может, и клюнет. А про "вставляйте код функции там,
где хотите вызвать функцию" это просто СУПЕР-фраза! Дерзайте, начинающие! Когда будете сопровождать все эти куски кода - глядишь, и программировать научитесь. :smile:  
Страницы: 1
Читают тему
Наверх