[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте

Внимание

Для участия в обсуждениях и оформления подписки на новые сообщения форума вам необходимо зарегистрироваться.
Главная » Основные форумы » Программирование на языке Lua
Страницы: Пред. 1 2 3 4 5 6 След.
RSS
[BUG] Повышенная загрузка CPU при большом количестве функций в скрипте
 
#101
29.12.2021 06:57:09
Цитата
TGB написал:
В ниже приведенном коде выделена строка символами ###, которая в QUIK 9.3.1.11 (QLua 5.4) выполняется в 16,25 раз дольше чем в QUIK 8.13.1.16 (QLua 5.4)
 Где поддержка??
Код
   --- Загрузка CPU --- 
IsRun  =   true 
 function   main ()
     local  T
    local  hour  =   0 , N
   N  =   1000000 
     ------------------- 
     while  IsRun  do  
       T  =   os.clock () 
       for  i  =   1 , N  do  hour  =  {}  end       
      T  =  ( os.clock ()  - T)  *   1000  / N      ---- ### !! Без подключения к серверу: 1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
                                                                 ---                                                         2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше) 
       message  (tostring(T))
         sleep ( 500 )  
     end 
     ------------------ 
 end    
   
 function   OnStop ()
     IsRun  =   false 
     return   10000    
 end 
  
Правильно я понял, что Вы сравниваете 0.16 ms v 0.26 ms в разных задачах?
Но время минимального кванта для задачи 10 ms.  
Т е вы сравниваете величины разность которых можно объяснить затратами на выгружения одной задачи и загрузкой другой или разностью  приоритетом задач или  минимальным квантом времени для исполнения задачи.
Иначе говоря, особенностями обслуживания данных задач операционной системой.
 
 
#102
29.12.2021 13:26:57
Цитата
nikolz написал:
Правильно я понял, что Вы сравниваете 0.16 ms v 0.26 ms в разных задачах?
  Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:
Цитата
nikolz написал:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
 
 
#103
29.12.2021 18:01:31
Цитата
TGB написал:
Цитата
nikolz написал:
Правильно я понял, что Вы сравниваете 0.16 ms v 0.26 ms в разных задачах?
   Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:
Цитата
nikolz написал:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
Было бы неплохо, если бы Вы писали ед изм.
----------------------  
Но особой разницы в числе нулей нет.
---------------------
Дело в том, что в ваш пример некорректный.
0.00016  это 160 us
0.0026 это 2.6 ms
А минимальный квант времени задачи это 10 ms или 10 000 us
------------------  
У вас миллион циклов
Поток, исполняющий эти циклы может иметь низкий приоритет
и будет прерываться системой  
которая будет выгружать эту задачу
-----------------------
У меня к Вам вопрос.  С какой погрешностью Вы измерили эти величины?
или иначе какая стабильность этих показаний?
 
 
#104
29.12.2021 18:08:11
Цитата
TGB написал:
Цитата
nikolz написал:
Правильно я понял, что Вы сравниваете 0.16 ms v 0.26 ms в разных задачах?
   Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:
Цитата
nikolz написал:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
попробуйте исполнить Ваш тест вне квика и сравните время исполнения.
 
 
#105
29.12.2021 18:15:02
Цитата
TGB написал:
Цитата
nikolz написал:
Правильно я понял, что Вы сравниваете 0.16 ms v 0.26 ms в разных задачах?
   Вы поняли неправильно.  Задача одна и та же. Версии QUIK разные.
 Читайте:
Цитата
nikolz написал:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
Можете пояснить какое отношение этот тест имеет к QPUA библиотеке?
Что в нем из нее используется.
У Вас тест VMLua.
 
 
#106
29.12.2021 18:15:37
Можете пояснить какое отношение этот тест имеет к QLUA библиотеке?
Что в нем из нее используется.
У Вас тест VMLua.
 
 
#107
29.12.2021 20:04:22
Цитата
nikolz написал:
попробуйте исполнить Ваш тест вне квика и сравните время исполнения.
 Предложение почти гениальное, особенно с учетом того, что обуждается проблема производительности скриптов в QUIK  :smile:
 У вас нет понимания, что при встраивании Lua в QUIK его разработчиком вносятся изменения, которые способны изменить встроенного Lua?

Цитата
nikolz написал:
Дело в том, что в ваш пример некорректный.0.00016  это 160 us0.0026 это 2.6 ms
  Переведите все в терасекунды и вам все станет понятнее  :smile:

Цитата
nikolz написал:
У Вас тест VMLua.
  Спасибо. А то я этого не знал  :smile:
 
 
#108
30.12.2021 11:15:40
TGB, Нет никакой "проблемы производительности скриптов в QUIK". Обсуждается проблема: "как можно засрать код на Lua, чтобы процессор сдох". По-моему, я уже советовал здесь обратиться к Биллу Гейтсу как к профессионалу высочайшего класса в таких делах.
 
 
#109
30.12.2021 14:28:28
Очень хочется увидеть ответ от разработчиков по поводу изучения данной проблемы, хотя бы после новогодних праздников. Ниже описывается пример, как большое количество таблиц может появляться в реальной программе.

Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей (сколько отдаёт сервер при запросе данных по ликвидным инструментам) по 10 инструментам и 5 таймфреймам. Время свечи QLua отдаёт в виде таблицы

Код
datetime = { year = 2021, month = 12, day = 30, hour = 11, min = 0, sec = 0, ms = 0, mcs = 0, ... }

Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.

Конечно, конкретно здесь можно закодировать дату в виде строки "2021-12-30T11:00:00.000" или вообще числом 20211230110000000 для эффективности, но придётся писать код для выделения из этого числа отдельных полей, и арифметика даты/времени станет неудобной.

В общем, просьба к разработчикам дать обратную связь, а то уже нехорошо выглядит такая техподдержка. Хоть пообещайте что-нибудь, как обычно.
 
 
#110
30.12.2021 15:18:15
_sk_, Серьёзно?! И КАК ЖЕ "большое количество таблиц может появляться в реальной программе"? Прям заинтриговали! :smile:

Ща посчитаем, сколько у меня... одна таблица для тикеров, одна для формирования транзакций, две таблицы Квика (одна для тикеров, другая для контекстного меню), да 10 служебных, "никакого" объёма, проинициализированных прямо в коде - И ВСЁ! Сейчас у меня запущено три скрипта, то бишь общее число таблиц 14*3=42. Процессор у меня 2 ядра по 2 ГГц, ОЗУ 2 ГБ, запустил я их сегодня где-то в 8 утра, так все три и работают. Обслуживают они в общей сложности 194+919+1934=3047 тикеров, у каждого по 10 таймфреймов, причём минимальный даже не минутный, а 7.5 секунд, т.е. свечи у каждого тикера только на 4 младших таймфреймах обновляются 15 раз в минуту. Мало того: все свечи скрипт считает САМ!
Цитата
Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей
Нет, ТАКОГО мы предполагать не будем, ибо НЕ СУЩЕСТВУЕТ В ПРИРОДЕ скриптов, которым нужно хранить в памяти для работы 3000 свечей! А вот что "столько отдаёт сервер при запросе данных по ликвидным инструментам" - это алгоритмический КРЕТИНИЗМ, и только от меня дважды регистрировали пожелание заменить этот БСК нормальной структурой данных.

Я понятия не имею, на кой вообще нужно время - мне, как и моему скрипту, совершенно безразлично, когда сработала заявка: сейчас или через час, но загонять это дело в таблицу - ещё один кретинизм, ибо порядковый номер свечи, который даже хранить не надо, ОДНОЗНАЧНО идентифицирует её время (если известна база и период свечей, а они по определению известны).

В общем, повторная просьба: отвяжитесь от разработчиков, не заставляйте их гробить софт реализацией своих идиотских пожеланий - он и без того глючный до невозможности. Учитесь лучше программировать, и будет вам ЩАСТЬЕ!
 
 
#111
30.12.2021 15:52:57
Цитата
_sk_ написал:
Очень хочется увидеть ответ от разработчиков по поводу изучения данной проблемы, хотя бы после новогодних праздников. Ниже описывается пример, как большое количество таблиц может появляться в реальной программе.

Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей (сколько отдаёт сервер при запросе данных по ликвидным инструментам) по 10 инструментам и 5 таймфреймам. Время свечи QLua отдаёт в виде таблицы

Код
  datetime  =  { year  =   2021 , month  =   12 , day  =   30 , hour  =   11 , min  =   0 , sec  =   0 , ms  =   0 , mcs  =   0 ,  .. . }
  

Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.

Конечно, конкретно здесь можно закодировать дату в виде строки "2021-12-30T11:00:00.000" или вообще числом 20211230110000000 для эффективности, но придётся писать код для выделения из этого числа отдельных полей, и арифметика даты/времени станет неудобной.

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

_sk_,

вы видите проблему, где ее нет

function main()
t = {}
for i = 1,150000 do
t[i] = os.time()
end
while true do
sleep()
end
end

запустите, посмотрите размер занимаемой памяти.
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
 
#112
30.12.2021 22:42:58
1.
Цитата
Владимир написал:
просьба: отвяжитесь от разработчиков, не заставляйте их гробить софт реализацией своих идиотских пожеланий
 Я бы на месте АРКИ зачислил вас в нештатные сотрудники  :smile:
---
2. Конечно, при разработке скриптов желательно чтобы они были (выполняя свои функции) как можно проще и допускали простоту последующей модификации.
    Рыночная эффективность торговой стратегии (ее доходность на определенном перио-де) может не сильно коррелировать с ее сложностью. Поэтому при разработке скрипта имеет смысл начинать с простых стратегий, не требующих много данных и вычислений и только потом добавлять учет дополнительных факторов поведения рынка.
    QUIK не то место, в котором надо заниматься событийным программированием, существенно усложняющим скрипты. Колбеки следует использовать по минимуму. Лучше от-слеживать доступные в QLua состояния рынка, а также состояния выполнения заявок. Заявки лучше использовать только лимитированные, иначе будут возникать рыночные по неконтролируемым ценам. Все сложные заявки системы: со стопами, тейки, айзберги и т.д., если вдруг они требуются, лучше реализовать в самом скрипте с использованием комбинаций лимитированных заявок. Собственные сложные заявки, будут выполняться с некоторой задержкой по времени (по сравнению с системными), во многом определяемой качеством канала связи с вашим брокером, но за это вы будете иметь более полный контроль над ними.  
----
3.
Цитата
Владимир написал:
TGB , Нет никакой "проблемы производительности скриптов в QUIK".
 Во втором пункте я написал, что скрипты желательно создавать простыми, Но это вовсе не означает, что инструмент для их создания должен быть «корявым». И когда после очередного изменения QUIK, создание таблиц в OLua начинает выполняться в 16 раз дольше, чем до изменения, то это оскорбляет «мои эстетические чуства»  :smile: . Вы понимаете, что в QLua фактически единственный тип это таблица с индексами/ключами и полями (известных типов)?  Замедление в 16 раз это аномальное поведение QLua, с которым должны были разобраться разработчики QUIK. Что они и сделали, выпустив версию QUIK 9.3.3.3, в которой этого замедления нет. Это не значит, что в этой версии нет проблем, о которых написали другие пользователи (это надо проверять). То, что в QUIK возникают и исправляются ошибки это нормально. Главное это чтобы исправленных было больше чем возникших. Плохо то, что поддержка не дает четкого объяснения возникающих ситуаций.
----
  Для того чтобы не разбираться с новыми глюками новых версий QUIK, у вас есть воз-можность выбрать существующую версию с «любимыми» вами глюками  и оставаться на ней столько, сколько вам захочется.
 
 
#113
31.12.2021 00:26:11
TGB, Я не зачисляюсь в сотрудники - ни штатные, ни нештатные. Всё, пенсионер я! :smile:

Ну да, я и "начал с простых стратегий, не требующих много данных и вычислений" - ими же и закончил! :smile:

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

Колбеки следует использовать по минимуму - согласен. Потому-то у меня их всего два: OnStop, да OnTrade. И заявки у меня только лимитированные, с самого начала. И задержку при подаче заявок сделал не более, чем раз в полсекунды, чтобы Квик не захлебнулся при бурных событиях на рынке (организовал для этого стек заявок), и снятие заявок не раньше, чем через полминуты, чтобы гарантированно пришла вся эта колода прерываний на одно событие, и качество канала связи с моими брокерами меня полностью устраивает, хотя инструмент для создания скриптов именно «корявый» - даже не знаю, видел ли я когда-нить худший язык. Но вот скорость создания таблиц в OLua меня совершенно не волнует - пусть выполняется хоть в 160 раз дольше, чем до изменения - слова против не скажу!

Да, я понимаю, что "в QLua фактически единственный тип это таблица с индексами/ключами". У меня почти мгновенно ключи стали косить под индексы, то бишь все числовые, и доступ к элементам разветвлённого дерева вроде:
SetColor(T,a[i][0][9],4,D[X(a[i][2][2])],0,-1,-1);
или:
a[i][2][4]=a[i][2][0]/a[i][4][0][a[i][1][4][0]-1]*100-100;
проходит с вполне приличной скоростью, и создание вместе с инициализацией этой (фактически единственной) таблицы в мейне проходит в 100500 раз быстрее, чем загрузка самого Квика - ну что ещё желать-то? А больше всего боюсь именно очередного изменения QUIK, после которого перестанет работать то, что хоть как-то работает.

Ох, не уверен, что "есть возможность выбрать существующую версию с «любимыми» вами глюками и оставаться на ней столько, сколько вам захочется! Я бы никогда не ушёл с NT5/Win-2000, а сейчас из последних сил держусь на Хрюше на одном из моих компов (на других, увы, десятки). А недавно Яндекс залудил: "Ваш браузер устарел и не поддерживает новые возможности" - это в сраной-то почте?! Старый софт выдавливают, и буквально заставляют переходить на новое говно! Давайте хотя бы Квик не будем трогать, пока он ещё позволяет торговать!
 
 
#114
31.12.2021 08:16:15
Цитата
TGB написал:
Цитата
nikolz написал:
попробуйте исполнить Ваш тест вне квика и сравните время исполнения.
  Предложение почти гениальное, особенно с учетом того, что обуждается проблема производительности скриптов в QUIK  ::
 У вас нет понимания, что при встраивании Lua в QUIK его разработчиком вносятся изменения, которые способны изменить встроенного Lua?

Цитата
nikolz написал:
Дело в том, что в ваш пример некорректный.0.00016  это 160 us0.0026 это 2.6 ms
   Переведите все в терасекунды и вам все станет понятнее  ::

Цитата
nikolz написал:
У Вас тест VMLua.
   Спасибо. А то я этого не знал  ::
Судя по Вашему нытью Вы этого не знаете.
-----------------------
VMLua - никакого отношения к КВИКУ не имеет.
-------------------------
Разработчики КВИКА ничего в нее не добавляют и не являются авторами VMLua.
-----------------------------
Поэтому Ваши претензии не по адресу.
 
 
#115
31.12.2021 08:21:10
Цитата
s_mike@rambler.ru написал:
Цитата
_sk_ написал:
Очень хочется увидеть ответ от разработчиков по поводу изучения данной проблемы, хотя бы после новогодних праздников. Ниже описывается пример, как большое количество таблиц может появляться в реальной программе.

Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей (сколько отдаёт сервер при запросе данных по ликвидным инструментам) по 10 инструментам и 5 таймфреймам. Время свечи QLua отдаёт в виде таблицы

 
Код
    datetime   =   { year   =     2021  , month   =     12  , day   =     30  , hour   =     11  , min   =     0  , sec   =     0  , ms   =     0  , mcs   =     0  ,   ..  . }
    
 
Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.

Конечно, конкретно здесь можно закодировать дату в виде строки "2021-12-30T11:00:00.000" или вообще числом 20211230110000000 для эффективности, но придётся писать код для выделения из этого числа отдельных полей, и арифметика даты/времени станет неудобной.

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

_sk_,

вы видите проблему, где ее нет

function main()
t = {}
for i = 1,150000 do
t = os.time()
end
while true do
sleep()
end
end

запустите, посмотрите размер занимаемой памяти.
"И Остапа понесло"
 
 
#116
02.01.2022 07:13:36
Цитата
nikolz написал:
VMLua - никакого отношения к КВИКУ не имеет.
   Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипта ?:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
    -----

Вам не лень всякий раз цитировать комментарии пользователей полностью?
Не можете удержаться перед халявой?
Вы же так можете разорить АРКУ на накопителях базы форума  :smile:
 
 
#117
02.01.2022 10:42:30
TGB,
Цитата
Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипт
Некачественными замерами. :smile:  
 
 
#118
02.01.2022 14:28:59
Цитата
Владимир написал:
Некачественными замерами.   :smile:  
 Это вы под ником nikolz комментарии пишите?  :smile:
 
 
#119
02.01.2022 19:06:26
TGB, Началось!.. Вернее, продолжилось: сначала меня с Борькой посчитал "одним человеком" какой-то придурошный "опер", теперь снова... нет у меня никаких ников, и не было никогда. А если nikolz писал то же самое, то а данном случае я с ним согласен.
 
 
#120
03.01.2022 08:26:32
Цитата
TGB написал:
Цитата
nikolz написал:
VMLua - никакого отношения к КВИКУ не имеет.
    Ну и как вы объясните 16-ти кратную разницу времени выполнения скрипта ?:
1) В QUIK 8.13.1.16 (QLua 5.4)  T = 0,00016 ;      
2) В QUIK 9.3.1.11 (QLua 5.4)  T = 0,0026  ??? (в 16,25 раз дольше)
    -----

Вам не лень всякий раз цитировать комментарии пользователей полностью?
Не можете удержаться перед халявой?
Вы же так можете разорить АРКУ на накопителях базы форума  ::
Я Вам ранее пытался объяснить расхождение в Вашем тесте, но Вы очевидно не увидели.
-----------------------------
Поясню еще раз.
Вы проверяете две различные задачи Причем в каждой из них Вы в отдельно открытом потоке исполняете цикл 1 млн раз.
---------------------------------------
Винда это многозадачная операционная система. Для каждой задачи дается интервал с квантом не менее 10 мс.
---------------------------------------------
Если выделенный квант для задачи исчерпан, но задача не завершилась, то OC выгрузит ее текущее состояние и загрузит другую задачу потом следующую и так по очереди с учетом приоритетов.
--------------------  
Таким образом время исполнения Ваших циклов зависит не только от скорости VMLua, но и от наличия других задач и служб ОС .
------------------------  
Хотите корректно протестить используйте HiResTimer
его квант измерения времени  исполнения составляет примерно 0.1 мкс. Он позволит Вам не делать миллион циклов для измерения времени исполнения
Но при этом Вы увидите, что результаты будут изменятся от измерения к измерению.
--------------------------  
Но хочу обратить  внимание на тот факт, что в Вашем тесте нет функций из библиотеки QLUA
Т е Вы тестируете ядро VMLua, а его разработчики КВИК ставят без своих костылей на основе исходников LUA.
------------------------
 
 
#121
03.01.2022 12:09:41
Цитата
nikolz написал:
Поясню еще раз.
 Без учета эффекта Доппера и спина электрона  ваше объяснение не канает  :smile:
 
 
#122
03.01.2022 16:49:14
Цитата
Владимир написал:
А если nikolz писал то же самое, то а данном случае я с ним согласен.
  Декларация вашего мнения в данной ситуации не очень существенна. Оно уже многократно вами озвучено и старо как этот мир: не пущать  :smile:  Но жизнь не остановить. Будут новые версии QUIK. Будут в нем ошибки и исправления. Странно то, что вы с этим продолжаете безнадежно бороться. Вы что, жизни не видели?
 
 
#123
03.01.2022 18:49:55
TGB, Моё мнение сроду не было "не пущать". Ни секунды не сомневаюсь, что "будут новые версии QUIK". Ни секунды не сомневаюсь, что каждая новая будет хуже предыдущей. Но ЮЗЕРАМ-то за каким хреном всё это надо? Ещё чёрте когда, ещё в 2011 году я писал (про браузеры):

Все компании, как заведенные, штампуют очередные версии, невзирая на реальное количество новшеств в них. Более того, они теперь приловчились и обновлять их автоматически, втихаря от юзера. Иными словами, значительная часть пользователей перейдёт на обновленную версию... даже не заметив этого "радостного" момента! Господа, но ведь это же ДОКАЗАТЕЛЬСТВО, что все эти браузеры есть полное дерьмо - ВСЕ ДО ЕДИНОГО! Если уж даже САМИ РАЗРАБОТЧИКИ не выдерживают - менее, чем через месяц выбрасывают очередное свое поделие на свалку... какие уж тут "новые возможности"!
- Не успел опробовать мозиллу 364 как уже 366 пришла...
- А я даже скачать не успел. Там вроде всей разницы - увеличили таймаут, по которому плагин считается зависшим. Но, видимо, сочли это настолько значимым, что даже пропустили цифру.
Так почему же юзеры, как заведённые, с упорством носорога, качают и качают эти очередные версии?! Ну нельзя же быть настолько тупыми, господа!
(...)
Ещё более смешны разговоры о безопасности применительно к браузеру - ведь это всего лишь паршивая прикладная задача. Более того - та самая, которая постоянно лазит по всяким помойкам, и тащит в рот всякую гадость. И Вы поверили, что именно эту программу и отрядили, чтобы "противостоять попыткам проникновения в систему"?! ДА КАКОЕ ЕЁ СОБАЧЬЕ ДЕЛО?! Пусть ковырятся в своей выделенной песочнице - и дело с концом Успокойтесь господа! Все эти "шпионские страсти" и "вирусные инфекции" - ничто, по сравнению с кошмариками в исполнении тупорылых "защитничков" - вот кого нам действительно следует бояться! С другой стороны, бояться какого-то тупорылого стада... стыд и позор! Так что успокойтесь господа. Если вам всё равно страшно - накапайте себе валерьянки. Или выпейте водки. Или возьмите топор, да изрубите ваш комп в капусту. Или хотя бы послушайте, что говорят про безопасность сами тупорылые - да, да, те самые, которые вас и пугают!
Эта характеристика сколь важна, столь и сложна в оценке. К сожалению, здесь нет (!) четких критериев, а каждое (!) исследование вызывает подозрения со стороны как пользователей, так и экспертов. Поэтому говорить собственно о безопасности браузера пока преждевременно (!). В общем-то, и материалов на эту тему найти не удалось (!).
Как видим, никто даже и не знает, что такое "безопасность браузера" - так, мычат что-то невразумительное насчёт "результатов ежегодных хакерских соревнований, на которых предлагается взламывать браузеры". Так чего же вы все так дружно обоср... испугались-то, господа? Да разве тупорылые дадут нас в обиду? Смотрите:
Вопрос сохранности частной жизни (!) приобретает особую (!) важность: если за ваш (!) компьютер кто-то (!) сел... Но работы над совершенствованием различных аспектов безопасности браузеров не прекращаются, и новые решения появляются практически в каждой (!) очередной версии. Все современные браузеры поддерживают приватный режим функционирования, в котором не сохраняются (!) следы посещённых веб-сайтов. Кроме того, реализован механизм, блокирующий на веб-страницах элементы, следящие (!) за перемещением пользователя. Полезная новинка - автоматическое упрощение URL в том случае, когда реальное имя сайта назначения передается (как правило, злонамеренно) в качестве параметра.
Примеры можно приводить бесконечно - от подобной бредятины Интернет просто ломится. Тем не менее, сказка про безопасность остается одной из самых популярных. Ну нельзя же быть настолько тупыми, господа!
(...)
Так что же это за таинственные "новые технологии", которые, оказывается, даже умудрились "войти в обиход"? Назовёт мне хоть кто-нибудь, хоть когда-нибудь, хотя бы одну? А вдруг окажется, что о них И НЕ НАДО было "думать"? Вдруг о них перестанут думать уже к выходу следующей версии браузера? А ведь перестанут - зуб даю! И куда, скажите на милость, подевались СТАРЫЕ технологии? Зачем их сп... гхм... украли?
Адаптировать браузер также не имеет смысла: придётся ограничить или вообще убрать практически все нововведения, так что он потеряет и свои преимущества.
Огласите весь список, пжалста! Хоть "нововведений", хоть "преимуществ". И вы немедленно убедитесь, что список этот даже не смехотворно мал - он просто-напросто ПУСТ! Ну нельзя же быть настолько тупыми, господа!
(...)
Война браузеров (грязная, беспощадная!) действительно была, я её и сам видел. Но она была между NN и IE! И в этой войне любые технические нюансы, достоинства и недостатки самих браузеров, не имели НИ МАЛЕЙШЕГО значения! А весь этот нынешний ублюдочный зоопарк из оперных хромированных лис есть лишь ИМИТАЦИЯ войны, лишь разводка для лохов. Я понимаю - вся эта погань из W3C и ниже мечтает рулить финансовыми потоками, она только на этом поганом клиенте ворует бабло десятками миллиардов долларов. НО НАМ-ТО КАКОЕ ДО ЭТОГО ДЕЛО?! Воруют - да и хер бы с ними, но они же еще и СРАТЬ ПРИХОДЯТ НА НАШИ КОМПЫ! Ну почему вы это терпите?! Ну нельзя же быть настолько тупыми, господа!
(...)
Был такой анекдот: "Абрам - нас, кажется, учат коммерции"! Не нужно считать одну из самых успешных компаний толпой идиотов: разводка для быдла КЛАССНАЯ! Дать им возможность почувствовать собственную состоятельность, поспорить, повыдвигать предложения, как нужно писать браузер... Они относятся к юзеру с полнейшим презрением - и правильно: он такого отношения более, чем заслуживает. Пока зомбированное быдло считает себя продвинутыми пользователеми, бизнес тупорылых будет успешным. Ну нельзя же быть настолько тупыми, господа!
(...)
Можно, например, проводить разнообразные тесты на "качество" браузеров. И неважно, что подобные тесты никогда не охватывают весь стандарт, неважно, что сами спецификации всё ещё находится на стадии обсуждения, и номинальная их поддержка мало о чем говорит, неважно, что на других аналогичных тестах результаты и лидеры могут быть совершено иными! Теперь можно вываливать на вконец одуревшего юзера ещё порцию макулатуры в стиле: Полезность такой новинки, как голосовой ввод, сомнительна, зато (!) она демонстрирует возможности HTML5. Надо признать, что и в этом лохотроне тупорылые одержали блестящую победу - мы лишь дружно надуваем щёки, да с важностью покачиваем головами: "Да, да, HTML5 - это круто, это прорыв". Ну нельзя же быть настолько тупыми, господа!
(...)
Тупорылые успели так загадить клиента, что знаменитые Авгиевы конюшни выглядят на этом фоне чуть ли не благоухающим садом! Одних только лохотронов о браузере (о каждом из которых можно писать многотомные опупеи) бесчисленное множество - файловая система и менеджер вкладок, плагины и расширения, меню и библиотеки, редактирование и поиск, графика и анимация, асинхроность и синхронизация, тормоза и глюки, не говоря уже про более конкретный зверинец: DOM, jQuery, GWT, AJAX, PHP, SEAM, Wicket, Greasemonkey, Silverlight, и прочую мерзость. Но ведь нужно же когда-то заканчивать статью!

А теперь замените "браузер" на QUIK и перечитайте ещё раз. :smile:  
 
 
#124
03.01.2022 19:06:04
Цитата
Владимир написал:
А теперь замените "браузер" на QUIK и перечитайте ещё раз.  
  У вас такой печальный опыт. У меня была счастливая возможность наблюдать, а иногда и участвовать в том, как качество программ программ, со временем, улучшалось.
  Надеюсь что и вам, если вы будете переходить на новые версии QUIK, выпадет (через год?) такое счастье  :smile: . А чтобы ощутить это сейчас, вы могли бы перейти на QUiK 8.5, а потом вернуться на версию, которую используете сейчас.
 
 
#125
03.01.2022 19:24:06
TGB, У МЕНЯ?! А у кого ИНОЙ опыт - поднимите руки! :smile:

Я за свою жизнь написал немало программ, мне доводилось видеть работу СУПЕР-профессионалов! А сейчас я задаю конкретный вопрос: что сделано из программного обеспечения за весь XXI век? Вернее, не так: сделано ли ХОТЬ ЧТО-НИБУДЬ? Огласите весь список, пжалста!

Мне пока что насрать на новые версии QUIK - мой скрипт пока что уживаются со всеми. А вот что будет через год - даже боюсь себе представить. Кстати, я понятия не имею, какую версию я использую сейчас... 8.7.1.3 у одного брокера и 8.13.3.1 у другого. Обе сейчас работают, часа два назад одна из них отвисла, пришлось убить Квик. Обе несколько раз обновлял, исключительно по рекомендациям брокеров.
 
 
#126
03.01.2022 19:30:13
Цитата
Владимир написал:
Мне пока что насрать на новые версии QUIK
  А почему бы вам не вернуться на исконно-посконную версию QUiK 8.5, которая, как я понимаю, с вашей точки зрения, более стабильная?
 
 
#127
03.01.2022 19:33:05
TGB, Я же сказал, почему: мне ВСЁ РАВНО какая версия. Брокер рекомендует вот эту? Берём под козырёк.
 
 
#128
03.01.2022 19:37:25
Цитата
Владимир написал:
TGB , Я же сказал, почему: мне ВСЁ РАВНО какая версия.
  А что же вы боретесь с новыми версиями?  :smile:
 
 
#129
03.01.2022 20:09:23
TGB, Потому что страшно! Перестанет ведь работать и то, что работает, если реализовывать все эти идиотские "пожелания"!
 
 
#130
03.01.2022 20:43:14
Цитата
Владимир написал:
TGB , Потому что страшно! Перестанет ведь работать и то, что работает, если реализовывать все эти идиотские "пожелания"!
   Я думал что вы бесстрашный  :smile:
   Вы же можете оставаться на "любимых" вами версиях (даже на QUIK 7....) достаточно долго (минимум, лет 5). Какие у вас проблемы?
 
 
#131
03.01.2022 21:01:08
Цитата
Владимир написал:
Брокер рекомендует вот эту? Берём под козырёк.
    Правильное решение  :smile:  С учетом того, что брокер в программах может не разбираться от слова "ничего". Вы же, в прошлом, разработчик должны бы понимать цену этим рекомендациям.
 
 
#132
03.01.2022 21:16:45
TGB, Да мне плевать! Как любой браузер должен корректно отображать любой сайт, так и любая версия Квика должна позволять корректно вести торговлю - тем более, рекомендованная самим брокером! У него просто не будет отмазки "используете неправильную версию".  :smile:  
 
 
#133
03.01.2022 21:19:48
TGB, У меня как раз НИКАКИХ проблем. Но даже я заметил, что Квик всё чаще стал отвисать. Да и может ли быть иначе, если в него вставлять все эти идиотские "доработки", наподобие той, которая вынесена в топик этой ветки?
 
 
#134
03.01.2022 21:24:02
Цитата
Владимир написал:
любая версия Квика должна позволять корректно вести торговлю - тем более, рекомендованная самим брокером! У него просто не будет отмазки "используете неправильную версию".    
 Ну тогда "хлебайте" то, что вам предлагают и не жалуйтесь на новые версии QUIK (вы же в них не работаете).
 
 
#135
03.01.2022 21:27:30
TGB, Я уже говорил: моя 32-разрядная Хрюша не поддерживается, мой старенький Хром, на ней стоящий, не устраивает теперь даже сраную Яндекс-почту, и меня перестало пускать на нём даже сюда! Захожу вот (пока что) с того же компа, но под Оперой. Надолго ли?
 
 
#136
03.01.2022 21:32:34
TGB, Во, блин - опять эта пидарасина отвисла на ровном месте (которая 8.13.3.1). Полчаса уж как висит, причём МОЛЧА! Как на таком говне работать?
 
 
#137
04.01.2022 07:01:23
Цитата
Владимир написал:

Ещё более смешны разговоры о безопасности применительно к браузеру - ведь это всего лишь паршивая прикладная задача. Более того - та самая, которая постоянно лазит по всяким помойкам, и тащит в рот всякую гадость. И Вы поверили, что именно эту программу и отрядили, чтобы "противостоять попыткам проникновения в систему"?! ДА КАКОЕ ЕЁ СОБАЧЬЕ ДЕЛО?! Пусть ковырятся в своей выделенной песочнице - и дело с концом Успокойтесь господа! Все эти "шпионские страсти" и "вирусные инфекции" - ничто, по сравнению с кошмариками в исполнении тупорылых "защитничков" - вот кого нам действительно следует бояться! С другой стороны, бояться какого-то тупорылого стада... стыд и позор! Так что успокойтесь господа. Если вам всё равно страшно - накапайте себе валерьянки. Или выпейте водки. Или возьмите топор, да изрубите ваш комп в капусту. Или хотя  бы послушайте, что говорят про безопасность сами тупорылые - да, да, те самые, которые вас и пугают!
Эта характеристика сколь важна, столь и сложна в оценке. К сожалению, здесь нет (!) четких критериев, а каждое (!) исследование вызывает подозрения со стороны как пользователей, так и экспертов. Поэтому говорить собственно о безопасности браузера пока преждевременно (!). В общем-то, и материалов на эту тему найти не удалось (!).
Как видим, никто даже и не знает, что такое "безопасность браузера" - так, мычат что-то невразумительное насчёт "результатов ежегодных хакерских соревнований, на которых предлагается взламывать браузеры". Так чего же вы все так дружно обоср... испугались-то, господа? Да разве тупорылые дадут нас в обиду? Смотрите:
Вопрос сохранности частной жизни (!) приобретает особую (!) важность: если за ваш (!) компьютер кто-то (!) сел... Но работы над совершенствованием различных аспектов безопасности браузеров не прекращаются, и новые решения появляются практически в каждой (!) очередной версии. Все современные браузеры поддерживают приватный режим функционирования, в котором не сохраняются (!) следы посещённых веб-сайтов. Кроме того, реализован механизм, блокирующий на веб-страницах элементы, следящие (!) за перемещением пользователя. Полезная новинка - автоматическое упрощение URL в том случае, когда реальное имя сайта назначения передается (как правило, злонамеренно) в качестве параметра.
Примеры можно приводить бесконечно - от подобной бредятины Интернет просто ломится. Тем не менее, сказка про безопасность остается одной из самых популярных. Ну нельзя же быть настолько тупыми, господа!
(...)
Так что же это за таинственные "новые технологии", которые, оказывается, даже умудрились "войти в обиход"? Назовёт мне хоть кто-нибудь, хоть когда-нибудь, хотя бы одну? А вдруг окажется, что о них И НЕ НАДО было "думать"? Вдруг о них перестанут думать уже к выходу следующей версии браузера? А ведь перестанут - зуб даю! И куда, скажите на милость, подевались СТАРЫЕ технологии? Зачем их сп... гхм... украли?
Адаптировать браузер также не имеет смысла: придётся ограничить или вообще убрать практически все нововведения, так что он потеряет и свои преимущества.
Огласите весь список, пжалста! Хоть "нововведений", хоть "преимуществ". И вы немедленно убедитесь, что список этот даже не смехотворно мал - он просто-напросто ПУСТ! Ну нельзя же быть настолько тупыми, господа!
(...)
Война браузеров (грязная, беспощадная!) действительно была, я её и сам видел. Но она была между NN и IE! И в этой войне любые технические нюансы, достоинства и недостатки самих браузеров, не имели НИ МАЛЕЙШЕГО значения! А весь этот нынешний ублюдочный зоопарк из оперных хромированных лис есть лишь ИМИТАЦИЯ войны, лишь разводка для лохов. Я понимаю - вся эта погань из W3C и ниже мечтает рулить финансовыми потоками, она только на этом поганом клиенте ворует бабло десятками миллиардов долларов. НО НАМ-ТО КАКОЕ ДО ЭТОГО ДЕЛО?! Воруют - да и хер бы с ними, но они же еще и СРАТЬ ПРИХОДЯТ НА НАШИ КОМПЫ! Ну почему вы это терпите?! Ну нельзя же быть настолько тупыми, господа!
(...)
Был такой анекдот: "Абрам - нас, кажется, учат коммерции"! Не нужно считать одну из самых успешных компаний толпой идиотов: разводка для быдла КЛАССНАЯ! Дать им возможность почувствовать собственную состоятельность, поспорить, повыдвигать предложения, как нужно писать браузер... Они относятся к юзеру с полнейшим презрением - и правильно: он такого отношения более, чем заслуживает. Пока зомбированное быдло считает себя продвинутыми пользователеми, бизнес тупорылых будет успешным. Ну нельзя же быть настолько тупыми, господа!
(...)
Можно, например, проводить разнообразные тесты на "качество" браузеров. И неважно, что подобные тесты никогда не охватывают весь стандарт, неважно, что сами спецификации всё ещё находится на стадии обсуждения, и номинальная их поддержка мало о чем говорит, неважно, что на других аналогичных тестах результаты и лидеры могут быть совершено иными! Теперь можно вываливать на вконец одуревшего юзера ещё порцию макулатуры в стиле: Полезность такой новинки, как голосовой ввод, сомнительна, зато (!) она демонстрирует возможности HTML5. Надо признать, что и в этом лохотроне тупорылые одержали блестящую победу - мы лишь дружно надуваем щёки, да с важностью покачиваем головами: "Да, да, HTML5 - это круто, это прорыв". Ну нельзя же быть настолько тупыми, господа!
(...)
Тупорылые успели так загадить клиента, что знаменитые Авгиевы конюшни выглядят на этом фоне чуть ли не благоухающим садом! Одних только лохотронов о браузере (о каждом из которых можно писать многотомные опупеи) бесчисленное множество - файловая система и менеджер вкладок, плагины и расширения, меню и библиотеки, редактирование и поиск, графика и анимация, асинхроность и синхронизация, тормоза и глюки, не говоря уже про более конкретный зверинец: DOM, jQuery, GWT, AJAX, PHP, SEAM, Wicket, Greasemonkey, Silverlight, и прочую мерзость. Но ведь нужно же когда-то заканчивать статью!

А теперь замените "браузер" на QUIK и перечитайте ещё раз. ::  
Прикольно.
---------------------
Опус типа:
"все телеги - говно.
А теперь замените слово телеги на любое другое существительное и прочитайте еще раз."
---------------------
"Тех, кто был особо боек,
Прикрутили к спинкам коек —
Бился в пене параноик,
Как ведьмак на шабаше.."
 
 
#138
04.01.2022 10:15:40
nikolz, Не вижу ничего "прикольного". Софт перестаёт работать, причём весь. В очередной раз задаю вопрос: сделано ли ХОТЬ ЧТО-НИБУДЬ за весь XXI век в сфере программного обеспечения, что могло бы быть расценено хотя бы как "полезное"?
 
 
#139
05.01.2022 08:21:10
TGB, хватит кормить троллей!


Цитата
s_mike@rambler.ru написал:
_sk_,

вы видите проблему, где ее нет

function main()
t = {}
for i = 1,150000 do
t[i] = os.time()
end
while true do
sleep()
end
end

запустите, посмотрите размер занимаемой памяти.

s_mike,  а где вы в ветке увидели про размер занимаемой памяти?
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#140
05.01.2022 10:46:45
Цитата
Старатель написал:
TGB, хватит кормить троллей!


Цитата
s_mike@rambler.ru написал:
_sk_,

вы видите проблему, где ее нет

function main()
t = {}
for i = 1,150000 do
t = os.time()
end
while true do
sleep()
end
end

запустите, посмотрите размер занимаемой памяти.

s_mike,  а где вы в ветке увидели про  размер  занимаемой памяти?
Я ещё раз прочитал сообщение _sk_, на которое я отвечал и да, речь идёт именно о занимаемой памяти скриптом, в котором очень много таблиц, описывающих дату/время.  
www.bot4sale.ru

Пасхалочка для Алексея Иванникова: https://forum.quik.ru/messages/forum10/message63088/topic7052/#message63088
 
 
#141
05.01.2022 11:16:11
Старатель, Вы здесь главный тролль и есть. Задолбали вечным скулежом по самым смехотворным проблемам! Программировать сначала научитесь, а уже потом доставайте техподдержку своими дурацкими пожеланиями. Впрочем, и потом тоже не надо.

s_mike@rambler.ru,
Цитата
и да, речь идёт именно о занимаемой памяти скриптом, в котором очень много таблиц, описывающих дату/время.
Причём ни одна из них не нужна, "ибо порядковый номер свечи, который даже хранить не надо, ОДНОЗНАЧНО идентифицирует её время". :smile: Курьеры, курьеры, можете представить себе, тридцать пять тысяч одних курьеров! Таблиц на несчастное время В ТЫСЯЧУ РАЗ больше, чем у меня на всё! Даже больше, чем в тысячу! При этом контроль по несчастным  "10 инструментам и 5 таймфреймам"! Какой CPU подобное издевательство выдержит? У меня вдвое больше таймфреймов, вдвое больше брокеров и в 100-200 раз больше инструментов. И процессор дохленький. И памяти два гига. И никаких проблем ни с памятью, ни с производительностью - только вот Квик всё чаще начинает виснуть "без объяснения причин", иногда - "неизвестное программное исключение", иногда "unknown hard error". Да и может ли быть иначе, если софт постоянно корёжить по заявкам таких вот деятелей?
 
 
#142
05.01.2022 11:17:30
Цитата
s_mike@rambler.ru написал:
Я ещё раз прочитал сообщение _sk_, на которое я отвечал и да, речь идёт именно о занимаемой памяти скриптом, в котором очень много таблиц, описывающих дату/время.  
Речь не о размере занимаемой памяти, а о количестве элементов в таблице.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#143
05.01.2022 11:20:27
Владимир до лысины дожил, а ума не нажил (С).
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#144
05.01.2022 11:53:20
Странный спор.

Берем тот же скрипт, приводим к универсальному виду:
Код
_G.message = _G.message or _G.print

_G.message('begin: '..tostring(os.clock()))
local t = {}
for i = 1,150000 do
    t = os.time()
end
_G.message('end: '..tostring(os.clock())..', memory: '..tostring(collectgarbage("count")))

В чистом lua:

begin: 0.0
end: 0.006, memory: 25.41796875

В Квике 8.13

begin: 1796.016
end: 1796.032, memory: 39.4013671875

В Квике 9.3

begin: 31.48
end: 31.499, memory: 39.4013671875


Да, разница с чистым lua есть, но не сказал бы, что это как-то мешает. Тем более, что накладные расходы при запуске скрипта в окружении терминала есть.

Что касается хранения таблиц, то, как правило, необходимы последние для расчета чего-то в скользящем окне. Остальное то зачем держать - вычистить, сборщик уберет со временем.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#145
05.01.2022 12:48:22
Цитата
Nikolay написал:
Странный спор.
Берем тот же скрипт

Я тут о таком не спорил, если чё.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#146
05.01.2022 15:47:40
Цитата
Nikolay написал:
Код
 for  i  =   1 , 150000   do 
    t  =   os.time ()
 end
Цитата
Nikolay написал:
begin: 0.0
end: 0.006, memory: 25.41796875

Только сейчас заметил: вы сравниваете время вызова библиотечной функции os.time() ?
Причём сравниваемые величины явно меньше погрешности измерения. А memory то почему по-вашему должны сильно отличаться?
На самом деле, разница в скорости в чистом луа и в квике есть. Причём, если запускать в main, то разница значительная.
Надо только цикл поболее брать.
Но ваш тест к теме имеет такое же отношение, как и война браузеров.
Надо делать так, как надо. А как не надо - делать не надо.
 
 
#147
05.01.2022 16:13:46
Это не мой тест. Я просто запустил вышеприведенный чужой код на чистом луа. И вижу, что я также ничего не вижу.
https://nick-nh.github.io/
https://github.com/nick-nh/qlua
 
 
#148
05.01.2022 16:31:50
Цитата
Nikolay написал:
Я просто запустил вышеприведенный чужой код

Надо делать так, как надо. А как не надо - делать не надо.
 
 
#149
10.01.2022 08:41:33
Цитата
_sk_ написал:
Очень хочется увидеть ответ от разработчиков по поводу изучения данной проблемы, хотя бы после новогодних праздников. Ниже описывается пример, как большое количество таблиц может появляться в реальной программе.

Предположим, что скрипту нужно хранить в памяти для работы 3000 свечей (сколько отдаёт сервер при запросе данных по ликвидным инструментам) по 10 инструментам и 5 таймфреймам. Время свечи QLua отдаёт в виде таблицы

Код
  datetime  =  { year  =   2021 , month  =   12 , day  =   30 , hour  =   11 , min  =   0 , sec  =   0 , ms  =   0 , mcs  =   0 ,  .. . }
  

Соответственно, сразу же имеем 3000 * 10 * 5 = 150 000 таблиц. А если скриптов несколько, то можно ещё на порядок увеличить количество таблиц в памяти.

Конечно, конкретно здесь можно закодировать дату в виде строки "2021-12-30T11:00:00.000" или вообще числом 20211230110000000 для эффективности, но придётся писать код для выделения из этого числа отдельных полей, и арифметика даты/времени станет неудобной.

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

Добрый день,

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

После того, как появится какая-либо резолюция, здесь будет написано соответствующее сообщение.
 
 
#150
18.01.2022 10:08:22
Добрый день,

К сожалению, нам не удалось воспроизвести и понять причину описанной вами проблемы.
 
 
Страницы: Пред. 1 2 3 4 5 6 След.
Читают тему
Техническая поддержка
+7 383 219 1606
© 2000–2024,
ARQA Technologies
Наверх