local n = 50000
for i = 1, n do
_G["f"..i] = function () end
end
local class = "SPBFUT"
local sec = "SiZ1"
local param = {"BIDDEPTHT", "OFFERDEPTHT"}
local run = true
function OnStop()
run = nil
end
function main()
assert(Subscribe_Level_II_Quotes(class, sec))
for i = 1, #param do
ParamRequest(class, sec, param[i])
end
while run do sleep(500) end
Unsubscribe_Level_II_Quotes(class, sec)
for i = 1, #param do
CancelParamRequest(class, sec, param[i])
end
end
function OnQuote(class_code, sec_code) end
function OnParam(class_code, sec_code) end
function OnAllTrade(alltrade) end
QUIK 9.3.1.11, Lua 5.4 Открыто, как минимум одно окно: стакан ликвидного инструмента. Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.
ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему. Без флуда!
Надо делать так, как надо. А как не надо - делать не надо.
Даже не так. Нагрузка на CPU пропорциональна количеству любых объявленных переменных (глобальных ?), в т.ч. функций (не обязательно выполняемых, а просто объявленных) в скрипте и/или подключаемых модулях и количеству колбеков, получаемых скриптом. Когда в QUIK открыты одна или несколько ТТТ с большим количеством бумаг, стаканы, ТОС, то скрипты, в которых есть колбеки по событиям из этих таблиц, при высокой активности торгов сильно тупят.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель написал: Демонстрационный скрипт: Скрытый текст
Код
local n = 50000
for i = 1 , n do
_G[ "f" .. i] = function () end
end
local class = "SPBFUT"
local sec = "SiZ1"
local param = {"BIDDEPTHT", "OFFERDEPTHT" }
local run = true
function OnStop ()
run = nil
end
function main ()
assert( Subscribe_Level_II_Quotes (class, sec))
for i = 1 , # param do
ParamRequest(class, sec, param[i])
end
while run do sleep ( 500 ) end
Unsubscribe_Level_II_Quotes (class, sec)
for i = 1 , # param do
CancelParamRequest(class, sec, param[i])
end
end
function OnQuote (class_code, sec_code) end
function OnParam (class_code, sec_code) end
function OnAllTrade (alltrade) end
QUIK 9.3.1.11, Lua 5.4 Открыто, как минимум одно окно: стакан ликвидного инструмента. Конечно, никто не запускает скрипты с тысячами функций, но при нескольких запущенных скриптах с десятками функций при высокой активности на бирже получаем нихилую загрузку CPU.
ЗЫ: У кого "один скрипт на все случаи жизни" с парой функций, может игнорировать эту тему. Без флуда!
Согласен, что всегда можно написать скрипт, который загрузит бессмысленными вычислениями любой супер компьютер. Но вопрос лишь в том, виноват ли в этом скрипт? ---------------------------------- Пару слов по существу проблемы (это мой опыт решения данной проблемы. При этом даже нейронная сеть на ХР c одним ядром загружает CPU не более , чем на 30%.) ------------------- 1) Снизить загрузку процессора можно простым сворачиванием окон квика. 2) Если в скрипте и его функциях используются циклы в историю данных, то это очень плохой скрипт. 3) Язык луа не предназначен для сложных вычислений (обработка больших массивов данных) поэтому используйте API C for Lua. 4) Вызов кобеков QLUA реализуйте в одном скрипте для любого количества роботов и скриптов, в которых используете данные колбеков 5) Не надо лазить постоянно в архив терминала, используйте таблицы луа для хранения получаемых с биржи и от брокера данных .
Владимир, nikolz, господа флудеры, в демонстрационном скрипте нет никаких вычислений от слова совсем. Колбеки, вызываемые скриптом, пустые и не должны были бы оказывать на CPU абсолютно никакого влияния. Не надо искать подвох в скрипте, он написан лишь с одной целью: продемонстрировать в первую очередь разработчикам Арки существенный баг в организации вызовов колбеков скриптами. По факту получается, что время, затрачиваемое на вызов колбека, существенно больше, чем выполнение кода в колбеке. C Владимиром согласен в одном: "математика есть полное говно". Вот только это не моя математика, а квиковская, в котором есть прямая зависимость между количеством объявленных переменных и производительностью. Я, конечно, догадываюсь, в чём тут дело. Но так быть не должно. Предлагаю вам воздержаться от засирания темы. Хотя кому я это пишу...
Надо делать так, как надо. А как не надо - делать не надо.
Старатель, Мы не слепые, господин флудер. В нормальных скриптах, не ставящих целью засрать процессор (в моём, например) нет НИ ОДНОЙ из этих дурацких 50000 "функций", НИ ОДНОГО вызова assert, НИ ОДНОГО Subscribe_Level_II_Quotes, НИ ОДНОГО ParamRequest, НИ ОДНОГО Unsubscribe_Level_II_Quotes, НИ ОДНОГО CancelParamRequest, НИ ОДНОГО OnQuote, НИ ОДНОГО OnParam, НИ ОДНОГОOnAllTrade. Из всех присутствующих в "демонстрационном скрипте" у меня есть только main, да OnStop. И (поэтому!) у меня нет ни малейших проблем с "организацей вызовов колбеков скриптами".
Это Вы сами додумались, что "колбеки, вызываемые скриптом, пустые и не должны были бы оказывать на CPU абсолютно никакого влияния" или подсказал кто?
Квиковская математика, разумеется, говно (как и сам язык), но даже она вполне способна организовать полноценную торговлю - настолько, что искать что-либо лучшее я просто не хочу.
Я про приведённый скрипт. А если main убрать - станет лучше? В целом в самом деле не понятно по каким критериям вы говорите, что есть загрузка процессора. А совсем этот скрипт остановить - какая загрузка? А запустить скрипт какая загрузка? И сколько ядер у вас процессор, чтобы отмасштабировать цифры. Потому как "большая загрузка" - не понятная вводная. Надо бы знать что такое небольшая для вас и наоборот что большая, в цифрах. Чтобы масштаб проблемы был понятен.
Все-же скрипты с кольеками есть буквально у всех и как-то не особо слышно чтобы тормозил от колбеков так, что прям работать невозможно.
Проверил у себя на компьютере. Вот 3 картинки: до запуска скрипта, после запуска скрипта и после запуска скрипта, где размер массива ещё увеличен в 10 раз. Видно, что загрузка процессора вырастает до максимума.
Просьба к техподдержке передать информацию разработчикам и написать соответствующее сообщение в этой теме.
Nikolay написал: о каких функциях речь? Любых пользовательских, или только о подписанных колбеках и функциях qlua?
Nikolay, В сообщении #2 уточнение: речь идёт о любых объявленных переменных. Возможно глобальных, но это не точно. Вы можете заменить блок создания переменных таким образом:
Код
_G["f"..i] = i
Естественно, в моменты низкой активности торгов, а тем более на демке, влияние на загрузку будет незначительно. Если только не увеличить количество переменных и/или скриптов. Можно ещё в скрипт добавить подписку на другие ликвидные инструменты, чтобы получать больше событий.
Цитата
swerg написал: А если колбеки убрать станет лучше?
Станет.
Цитата
swerg написал: какие именно колбеки убрать, от убирания которых становится лучше?
swerg написал: Чтобы масштаб проблемы был понятен.
swerg, сравните загрузку CPU при запущенном(ых) скрипте(ах) с блоком создания переменных
Код
_G["f"..i] = function () end
и без него. При открытых окнах (стаканы, ТТТ, ТОС) и при закрытии всех окон в квике.
Цитата
swerg написал: не особо слышно чтобы тормозил от колбеков
swerg, А кто догадается, что тормоза именно от вызова колбеков? Не от выполнения кода внутри колбека, а просто от вызова. В этой теме посмотрите #4 и #5 сообщения: https://forum.quik.ru/messages/forum10/message59837/topic6874/#message59837 Не факт, что там именно эта проблема. Но это легко проверить: 1) автору достаточно добавить в начало каждого колбека do return end и проверить загрузку 2) переименовать каждый колбек как-то так OnQuote -> OnQuote_ и снова проверить загрузку Если в 1-м случае нагрузка не изменится, а во 2-м уменьшится, то это - обсуждаемая здесь проблема.
Надо делать так, как надо. А как не надо - делать не надо.
Только сейчас разглядел создание 50 тыс глобальных переменных Ну и чего вы хотите? функция в ЛУА - это просто глобальная переменная типа "функция". Чтобы функцию вызвать - ее надо найти, на это, очевидно, уходит время. Давайте десятки миллионов глобальных переменных создадим и будем требовать оптимизации. Зачем? кому интересен этот сценарий??
Уверен, если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить. Т.е. это такое вполне понятное свойство интерптетатора Луа. Просто не надо заводить десятки тысяч глобальных переменных.
Так что в данном случае я согласен с первыми высказавшимися "флудерам". Завалить можно любую систему. Вот только не со всеми "завалами" есть смысл разбираться, ибо некоторые из них (как здесь) будут сугубо не жизненные.
swerg написал: Только сейчас разглядел создание 50 тыс глобальных переменных
Это количество было написано для саппорта, который проводит "нагрузочное тестирование" на демке, где количество событий на два порядка меньше, чем в реале. Чтоб потом не было разговоров, что все летает. На бою, естественно, и рядом нет тысячи переменных.
Конечно, я не учёл фактор теоретиков-флудеров.
Цитата
swerg написал: если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить.
Пруф в студию.
Надо делать так, как надо. А как не надо - делать не надо.
На бою, естественно, и рядом нет тысячи переменных.
У кого нет, а у кого и есть. Когда я тестировал данные от Финама, опрашивалось более 20000 тикеров два раза в секунду. И ничего, Квик справлялся.
Цитата
Пруф в студию.
Пруф уже в студии, и написан лично Вами. В частности, выделен мною как "особенно понравившийся". А вообще включите мозги: ЕСЛИ интерпретатору подсунули десятки тысяч переменных, ТО при обращении к любой из них он должен среди всей этой навозной кучи как-то НАЙТИ нужную.
swerg написал: Чтобы функцию вызвать - ее надо найти, на это, очевидно, уходит время.
У луа глобальные функции/переменные находятся в таблице, а поиск в таблице луа заявлен как O(1), не должно бы по идее влиять, по крайней мере заметно влиять. Квик ничего не выдумывает, берет колбек из скрипта через lua_getglobal, так что вопрос интересный, как оно так вышло. Например, может тормозить поиск не в таблице по ключу, а самого ключа (строки), там вроде какой-то кэш строк есть, и при числе именованных переменных сильно больше его размера можем получать постоянный кэшмисс. А можем и не получать, рыть надо.
Anton написал: вопрос интересный, как оно так вышло
Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг. Вот оно собсна и есть, пропорционально количеству потенциального мусора. Насколько это критично в реальном применении, а не в модельном примере, вопрос открытый. Сама по себе идея синхронно прибраться в основном потоке выглядит хорошей, чутка пошаманить с частотой этого действа разве.
Anton, Мало ли что у них заявлено! К тому же, это наверняка "в среднем", а не в худшем случае. Да и число переменных они тестировали дай бог в пару сотен (если вообще тестировали).
Башку чем-нибудь околокодовым забить, пока заняться нечем.
Цитата
Владимир написал: наверняка "в среднем", а не в худшем случае
Хэш-таблица плюс хвост из новодобавленного с периодическим рехэшем, в итоге амортизированное O(1). Так-то, если слишком рано в бесконечные не уходить, сложность хэш-таблицы O(N/M), где M - число входов, в (самом) худшем просто считаем N/M->N и получаем O(N), типа такая вырожденная хэш-таблица с одним входом.
Пока биржа не тогует, решил проверить одну идею на демке. Junior, настройки по-умолчанию. Открыл три окна: ТОС, системные сообщения и доступные скрипты. В ТОС добавил неторговый класс SMS-оповещения, чтобы не мешала измерениям.
Далее запустил одновременно три копии скрипта:
Скрытый текст
Код
local function f(n)
for i = 1, n do
_G["f"..i] = function ()
return 0
end
end
end
local function r(n)
for i = 1, n do
local a1, a2, a3, a4, a5, a6, a7, a8, a9, a10 = 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
_G["f"..i] = function ()
return {a1, a2, a3, a4, a5, a6, a7, a8, a9, a10}
end
end
end
--f(150)
--r(150)
--require("socket")
--require("socket.smtp")
--require("iuplua")
local run = true
function OnStop()
run = nil
end
local t
function OnAllTrade()
if getNumberOf("all_trades") == 1 then
local num = 1
function OnAllTrade(alltrade)
num = num + 1
if num == 200000 then run = false end
end
t = os.clock()
end
end
function main()
while run do sleep(1) end
if t then message(tostring(os.clock() - t)) end
end
Перезаказал обезличенные сделки: Система / Настройки / Основные настройки... -> «Программа» / «Получение данных» / «Обезличенные сделки». Выбираю класс "Акции 1-го уровня (эмулятор)" -> "Перезаказать данные" По завершению работы скриптов запоминаю время.
Далее повторяю процедуру с f(150). Время работы скриптов выросло на 25%. С r(150) - на 80%-90%. При подключении socket время также увеличилось в 1,8 раза. А с iuplua в 3 раза.
Так что, дело тут не только в глобальных переменных.
Надо делать так, как надо. А как не надо - делать не надо.
До кучи решил ещё одну тему проверить. swerg, то, что вы написали
Цитата
swerg написал: если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить. Т.е. это такое вполне понятное свойство интерптетатора Луа.
- бред и не соответствует действительности: в чистом Lua время вызовов пустой функции никак не изменится даже после создания "десятков миллионов глобальных переменных". Коль ввязываетесь в спор, вы бы хоть проверяли, прежде, чем чё-то писать.
Надо делать так, как надо. А как не надо - делать не надо.
Даже просто создание локальной таблицы снижает производительность. Методика тестирования описана в сообщении #20
Код
local run = true
function OnStop()
run = nil
end
local t
function OnAllTrade()
if getNumberOf("all_trades") == 1 then
local num = 1
function OnAllTrade(alltrade)
num = num + 1
if num == 200000 then run = false end
end
t = os.clock()
end
end
function main()
local a = {}
local n = 0
--local n = 20000
for i = 1, n do a[i] = i end
while run do sleep(1) end
if t then message(tostring(os.clock() - t)) end
end
Получается, кеширование любых данных, например для расчётов индикаторов, снижает производительность при вызовах колбеков.
Надо делать так, как надо. А как не надо - делать не надо.
Старатель, Создание - снижает, это нагрузка на таблицы Квика. Собственно, не на создание, а на "созерцание". Тем более, не просто таблицы, а ТОС, которая нафиг никому не нужна. Индикаторы, тоже снижают, по той же причине. А вот если не заниматься подобной фигнёй и оставить только OnTrade, да обработчики, устанавливаемые по SetTableNotificationCallback, да поставить не sleep(1), а хотя бы sleep(500), то "производительность при вызовах колбеков" не просто удовлетворительная, а почти идеальная.
swerg написал: Давайте десятки миллионов глобальных переменных создадим
А давайте, чё мелочиться! Скрипт:
Скрытый текст
Код
local function v(n)
for i = 1, n do
_G["v"..i] = i
end
end
v(0)
--v(10000000)
local run = true
function OnStop()
run = nil
end
local t
function OnAllTrade()
if getNumberOf("all_trades") == 1 then
local num = 1
function OnAllTrade(alltrade)
if not run then return end
num = num + 1
if num == 200000 then run = false end
end
t = os.clock()
end
end
function main()
while run do sleep(500) end
if t then message(tostring(os.clock() - t)) end
end
Методика тестирования описана в сообщении #20. Только в этот раз я запускал только один экземпляр скрипта. Результаты тестирования в различных версиях QUIK при 0 и 10000000 глобальных переменных:
Старатель, А обращаться к этим "миллионам переменных" Пушкин будет? Вы всего лишь создали навозную кучу, но не ковырялись в ней в поисках нужной переменной.
Поправка к коду в сообщении #25: время надо фиксировать в самом колбеке. Но это не сильно влияет на итоговый результат: завышение результата на 0 - 0.5 сек.
Скрытый текст
Код
local function v(n)
for i = 1, n do
_G["v"..i] = i
end
end
v(0)
--v(10000000)
local run = true
function OnStop()
run = nil
end
local t
function OnAllTrade()
if getNumberOf("all_trades") == 1 then
local num = 1
function OnAllTrade(alltrade)
if not run then return end
num = num + 1
if num == 200000 then
t = os.clock() - t
run = false
end
end
t = os.clock()
end
end
function main()
while run do sleep(500) end
if t then message(tostring(t)) end
end
Надо делать так, как надо. А как не надо - делать не надо.
Старатель, Лапуль, я прекрасно понимаю о чём тема, и в первом же своём сообщении написал: "Вся тема есть чистейший флуд на 146%".
А чуть дальше столь же русским языком написал: "ЕСЛИ интерпретатору подсунули десятки тысяч переменных, ТО при ОБРАЩЕНИИ к любой из них он должен среди всей этой навозной кучи как-то НАЙТИ нужную".
swerg написал: если вы просто возьмете Луа без привязки к квик - вызов среди десятков тысяч переменных тоже будет тормозить.
Пруф в студию.
Для экспериментов возьмем online lua https://qlua.ru/demo/ Результаты выходят не очень стабильными, но все же проведя пару десятков экспериментов и выкинув пару экстремально отличающихся результатов, получил следующее время выполнения: 100 глобальных переменных - 1,4753 сек 100 тыс. глобальных переменных - 1,5608 сек
Да, разница не фантастически великая. Но какая-то явно есть. Разница много меньше, чем в ваших экспериментах внутри квика, это стоит отметить.
Тестовый код:
Скрытый текст
Код
local function v(n)
for i = n, 1,-1 do
_G["v"..i] = i % 100
end
end
v(100000) -- max 100000 by memory limit
local t = os.clock()
for i = 0, 50000000 do
v56 = v75
end
t = os.clock() - t
print(tostring(v56))
print("time:"..tostring(t))
Деградация от версии к версии определённо печалит. Хоть я и поставил бы под сомнение корректность некоторых полученных результатов (v(0) больше, чем v(10000000) ??). Но, похоже, в 9.3 точно случилось что-то.
Что-то вы, ребятки, не то делаете... какая-то _G, панимаш... про которую пишут, что "в новых версиях Lua вместо _G теперь _ENV"... У одного вообще без обращений, у другого к паре переменных туеву хучу раз... ВОТ ТАК в моём понимании создаются локальные переменные:
Ах, у loadstring с локальными переменными проблемы - ну, сделаем глобальной.
Код
f=true;
N=1000;
J=0;
function main()
local i;
for i=0,N do
loadstring("v"..i.."="..i%100)();
end;
F=io.open(getScriptPath().."//TEST","w");
for i=0,N do
loadstring("J=v"..i)();
F:write("i="..i.." v"..i.."="..J.."\n");
end;
F:close(); -- закрываем входной файл
-- while f do
-- sleep(500);
-- end;
end;
function OnStop()
f=false;
return 500;
end;
А в закомментированных строчках к ним должны бы быть протестированы обращения к этим переменным, но мне лень думать, как это делать, ибо НОРМАЛЬНАЯ у Квика производительность! НОРМАЛЬНАЯ! Не нравится "нормальная" - скажу "идеальная"! Она непригодна разве что для этой долбаной HFT, но тому нужно чесать прямиком на биржу, чтобы ловить там свои сраные сотые доли процента. Просто писать надо уметь, а не плакаться здесь в жилетку по самым идиотским "проблемам".
_sk_ написал: Думаю, что очень актуальный вопрос поднят. Спасибо топик-стартеру за демонстрацию проблемы. От разработчиков терминала ждём пояснений.
Присоеденяюсь. ----- Деградация эффективности QLua показатель низкого качества реализации разработчиками QUIK встраивания Lua в QUIK. Эффективность выполнения скриптов QLua без обращения к API QUIK должна отличаться от Lua только затратами на операции lock/unlock в вызовах функций C-API QLua, а также в VM-QLua (ulock/lock) при вызове C-функций. Причем упомянутые операции в подавляющих случаях «холостые» (потоки не переключают). Все места вызова lock/unlock (ulock/lock) определены в кодах Lua разработчиком Lua. Разработчику QUIK достаточно корректно реализовать lock/unlock, например, используя критические секции, обеспечивающие эффективную синхронизацию. Вопрос к поддержке: какое «ноу-хау» обеспечивает деградацию эффективности QLua новых версий? -----
Цитата
Anton написал: Сложился паззл. Когда в девятой версии смотрел "чего нового" в отладчике, увидел, что после каждого колбека lua_gc добавили.
Интересное открытие (пишу без иронии). Вопрос к поддержке: a это зачем сделали? Хотелось бы чтобы разработчик QUIK пояснил как додумался до этого. Какие проблемы это решает?
Деградация производительности мешает утром, когда происходит подключение к срочному рынку и заново приходят все обезличенные сделки с вечерней сессии. Если скрипты реагируют на соответствующие коллбэки и скриптов много, то происходят жуткие тормоза даже на современном железе. Конкретно у меня, несмотря на то, что реакция на обезличенные сделки минимальная, обезличенные сделки прогружаются минут десять с включенными скриптами и раз в 10 быстрее с выключенными. Судя по загрузке процессора (Core i7 9700K), упираемся именно в него. Уверенность в том, что в терминале есть какая-то жуткая неэффективность в этом месте, почти стопроцентная.
Убедительная просьба к техподдержке донести до разработчиков информацию по данной проблеме. Старатель предоставил описание тестового стенда, который даже на QUIK Junior демонстрирует деградацию производительности терминала в 2 раза по сравнению в более ранними версиями.
swerg написал: Деградация от версии к версии определённо печалит. Хоть я и поставил бы под сомнение корректность некоторых полученных результатов (v(0) больше, чем v(10000000) ??).
Anton написал: после каждого колбека lua_gc добавили. Не обратил внимания только, полный или шаг. Вот оно собсна и есть, пропорционально количеству потенциального мусора.
Тут надо отметить, что, если в скрипте есть таблица, в которой постоянно добавляются и убираются элементы, то фактически количество элементов в таблицы будет только расти и никогда не уменьшаться. Например, имеем таблицу активных заявок orders с ключом order_num. Когда заявка становится неактивной, убираем её: orders[order_num] = nil. Но для сборщика мусора этот элемент будет продолжать существовать со значением nil, он не сможет его очистить. Чтобы удалить элемент из таблицы, надо полностью удалить саму таблицу. Т.о., объём потенциального мусора будет только расти со временем работы скрипта.
Цитата
Anton написал: Насколько это критично в реальном применении
У каждого своё реальное применение. Кто-то торгует только один инструмент, а другой весь рынок отслеживает. Кому-то и 200 стаканов мало. Сами понимаете, в каждом случае количество событий будет отличаться кардинально.
Надо делать так, как надо. А как не надо - делать не надо.
Anton написал: Насколько это критично в реальном применении, а не в модельном примере, вопрос открытый.
А вот в реальном применении: загрузка CPU сегодня на открытии основной сессии в 10 ч. Слева - QUIK 9, справа - QUIK 8 при одинаковых настройках и одинаковом количестве открытых окон. Отличие только в том, что в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. работы выполняется меньше, чем в 9.
Надо делать так, как надо. А как не надо - делать не надо.
Это новый режим в 5.4, генерационная сборка (а-ля дотнет новый), типа "сначала собрать свежий мусор, если все равно много осталось - тогда шаг по всему". Раз влияние есть, то хайли лайкли нагрузку действительно дает коллектор. Думаю, поиграть с параметрами стоит, может найтись удачная конфигурация, тогда останется ее как дефолтную предложить. На память не скажу, что куда крутить, надо в доки луа лезть.
В сообщении #41 опечатался. * в QUIK 8 скрипты торгуют, а в QUIK 9 режим торговли не включен, т.е. в 9 работы выполняется меньше, чем в 8. + в QUIK 8 на два скрипта больше. А нагрузка - сами видите.
Надо делать так, как надо. А как не надо - делать не надо.
Интересно, почему до сих пор техподдержка никак себя не проявила в этой теме? В заголовке ведь явно указано [BUG]. Похоже, придётся специальную тему в "Пожеланиях..." создать для ускорения реакции.
Владимир написал: Не баг и не фича. И уж точно "не до этих мелочей". Чем меньше техподдержка будет реагировать на подобные темы, тем лучше. Квик и без того грузится чуть ли не дольше, чем операционка - это ещё хрен бы с ним. А то, что он отвисает в самых безобидных ситуациях, иногда даже без входа в Сеть - это как? А то, что вообще вылетает, причём молча - взглянешь на комп, а один из моих Квиков как корова языком слизнула. А на всякие "неизвестные исключения" или даже "unknown hard error" я уже и внимание перестал обращать: не вылетела - и ладно. И упаси меня, Господи, от новых версий!
Теперь второй вариант: какие-то придурки понаоткрывают себе всяких таблиц, графиков, стаканов, заведут немеряное количество разных переменных, подпишутся на все возможные колбеки, да ещё скулят при этом: "Повышенная загрузка CPU" - баг, панимаш! И фонтанируют своими идиотскими предложениями: то им не так, да это не этак. Ручонки кривые, а не баг! С какой радости техподдержка должна таких уродов ублажать?
Просто , КВИК- это добротная телега. А некоторым мерещится студебекер лили даже ероплан. Вот они на этой телеге с обрыва и прыгают. И потом долго по форуму пишется : '...Твою мать, ...Твою мать,... Твою мать"
nikolz, Ну, и на Квик, и на язык я в своё время предостаточно матерился, так что "добротной" эту телегу я бы не назвал. Но она, по крайней мере, позволяет нормально торговать, а все эти долбаные "нововведения" лишают её этой возможности. Деньги же всё-таки, надёжность превыше всего! Любые изменения, снижающие надёжность, должны отбрасываться без рассуждений. А если не снижают - тут уже можно и выпендриваться.