Serge123 (Все сообщения пользователя)

Я отключал, как здесь написано:
https://vk.com/@scum_survival-algoritm-neigla

Как раз хотел спросить: какую задержку выставлять в main после цикла обработки очереди от OnAllTrade и OnQuote? Я сделал 10 мс, может, есть более правильная задержка?

Я попробовал его отключить, но Квик начал очень сильно тормозить, занятость ЦП 82%, только и делал, что крутил бублик вместо курсора мыши, я не смог ничего сделать. Поэтому отключение этого алгоритма не для этого 2-ядерного ПК. Попробую на другом ПК.

Спасибо, что напомнили, а то я в перфекционистско-программистском угаре действительно часто об этом забываю...

В диспетчере задач занятость CPU показывает 4-12% (память занята на ~40%), во время сделки занятость CPU подскакивает до 23%, (при свёрнутом окне Квика 13%), но, когда идёт много моих сделок, я ясно вижу торможение, возможно, в связи с проигрыванием короткого звука для каждой сделки. В это время слышны только звуки, содержимое окон сделок и заявок не обновляется, щелчки по стаканам для выставления заявок не отрабатываются по несколько секунд. Иногда приходится завершать скрипт, который записывает в файл стаканы и все сделки по инструменту.

И ещё я вижу торможение, когда окно "Доступные скрипты" располагаю поверх стаканов. В этом случае хорошо видно, что циферки занятости памяти напротив скрипта перерисовываются не мгновенно. Хотя, GPU в диспетчере тоже простаивает, как и CPU. Поэтому я не знаю, как объяснить это торможение. Если перенести это окно на фоновую область окна Квика, то циферки рисуются мгновенно.

Перед началом работы я в диспетчере задач на всякий случай ставлю процессу info.exe высокий приоритет. Но каких-то изменений в связи с этим я не заметил.

Сомнительно: не видно логики для неработоспособности этой функции в консольных программах. И в документации на сайте МС нет такого предупреждения... Аналогично для более современной функции PlaySound.
Как тогда МС вообще планирует использование звука в консольных программах??

В принципе, ясно. Тогда, получается, что у меня память не утекает? Надо попробовать запустить сборщик мусора явно и посмотреть, сколько памяти освободится.

Я сегодня ещё подумал, что м.б. дело ещё в том, что сейчас у меня ПК с 2-мя ядрами, поэтому ядра всё время заняты и переключаются для выполнения разных потоков. А поток сборщика мусора, как я понимаю, имеет наинизший приоритет, поэтому до его выполнения на этом моём ПК дело не доходит.

collectgarbage("collect") помогает, даже слишком: в момент запуска в окне "Доступные скрипты" показывается, что занято скриптом 36.53 Кб, потом память, как и раньше, растёт, а в конце, после вызова collectgarbage, она становится 35.43 Кб. Чтобы это увидеть, я после collectgarbage вставил sleep(1000). Но остаётся вопрос: почему сборщик мусора не освобождает память во время работы цикла??

И ещё я мог бы опубликовать свой скрипт, который записывает в файл стакан и сделки по OnQuote и OnAllTrade, чтобы народ посмотрел и сказал, почему он потихоньку увеличивает занятую память, хотя, файловых операций не выполняет? Но боюсь, что, если никто не знает, почему, то просто не ответят, чтобы не признавать, что кто-то что-то не знает. Был уже пример на такую тему: я спросил, почему mciSendString в dll работает, а в exe файле то же самое не даёт звука, даже привёл программку. Так никто не ответил (видимо, никто не знает и в Интернете ответ не находится).

Насколько я понимаю, сборку мусора вроде бы надо делать так: в структуре каждого объекта ставят счётчик ссылок на него, тогда сборщик мусора просто просматривает эту информацию и бысто освобождает память под объекты со счётчиками ссылок == 0. Но в Lua, похоже, сборщик мусора просматривает вообще всё, что попало и смотрит, есть ли там ссылки на какие-то объекты. А если в программе имеется таблица из миллиона таблиц, тогда что делать сборщику мусора, кроме как тормозить программу?

Хотя, т.к. изменения в стаканах приходят кучей, и вроде бы с каким-то наименьшим периодом (> 0.01 с.), то о точном времени здесь говорить не приходится.

Ошибся, время здесь я беру через ossysdate() опять же с моего ПК. Ни OnQuote, ни getQuoteLevel2 времени не дают (хотя, здесь кто-то просил об этом в 2015 г. нашей эры...)

Все времена содержат микросекунды, а время для содержимого стакана, естественно, берётся с моего ПК, а откуда мне его ещё взять (от getQuoteLevel2 вестимо...)? А время сделок, видимо, передаётся в OnAllTrade с сервера биржи(?)

В файлике a1.txt видно, что два рекорда по числу сделок с неизменным временем были не на аукционе открытия.
А почему время сделок не меняется, можно только предполагать, а может кто-то, кто сидит ближе к мосбирже, спросит у неё: как объясняется этот феномен?

Закачал сюда этот файл с содержимым стаканов и сделками:
drive.google.com/file/d/1fbPQM0Xfd-ULQFV7M0vBPW8m_6boaulj/view?usp=sharing
Там на 3-х отрезках за одно и то же время происходит > 300 сделок.
Рекорд 509 сделок, почему-то в этом месте много сделок с одной акцией, кто объяснит?
Где рекордные сделки искать, см. в файлике a1.txt.

Проверил, память утекает раза в 2 сильнее...
А где можно прочитать о нововведениях с примерами, я использовал только <const>, видел упоминание о <clear>, но поиск по документации в архиве lua-5.4.6.tar.gz с сайта lua.org не находит ни <const> ни аналогичных образцов...

Попробую присваивать ссылкам на таблицы nil, хотя, я не понимаю, что от этого изменится для сборщика мусора... Ссылке на таблицу можно присвоить nil, а потом можно ещё что-нибудь присвоить, а сборщик мусора не заметит, что было присвоено nil. А если переменная объявлена внутри блока, то после завершения блока она вроде бы должна сталь nil. А что, если будет опять передача управления в этот блок и опять эта переменная получит значение, это будет та же самая переменная, или на неё каждый раз будет выделятья память? Я этого не представляю. Каждый раз выделять память переменной в блоке, который может быть внутри цикла, - дорогое удовольствие с точки зрения быстродействия...

В прошлой версии скрипта эти таблицы передавались как параметры коллбэка, а таблица от getQuoteLevel2 была локальной переменной в OnQuote, поэтому ссылкам на эти таблицы я ничего не присваивал (а зачем?) Но память всё равно почему-то потихоньку утекала.

Интересно: как можно проверить, что мой вариант скрипта, в котором я перенёс обработку стаканов и обезл. сделок в main, имеет смысл? Мне кажется, что добавилось лишней работы в потоке main с разбором очереди, а в потоке Квика работа уменьшилась неощутимо...

Спасибо, интересно... А до вер. 5.4.1 этой ошибки не было?
Я подозреваю, что утечка памяти имеется не только при работе с файлами: как я вчера писал в другой ветке, мой скрипт по записи в файл содержимого стаканов и обезл. сделок потихоньку увеличивает занятую память, хотя в это время нет работы с файлом и я присваиваю false ссылкам на таблицы...

Может быть, дело было в том, что кто-то сделал крупную заявку по рыночной цене, а с другой стороны сервер просто пособирал лимитные заявки на эту сумму, и это можно сделать намного быстрее?

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

Работает, но память, занимаемая скриптом, понемногу растёт, хотя, я после обработки в main таблиц из очереди записываю на место ссылок на них false.

И на мой сегодняшний вопрос в https://forum.quik.ru/forum10/topic8600/ так никто и не ответил, видно, не знают, что сказать...    

Похоже, что всё хорошо: переделал скрипт, чтобы он обрабатывал очередь от коллбэков в main, всё работает.

Смутно помнится, в документации на lua.org я видел, что жизнь таблицы из параметров функции гарантируется до выхода из этой функции (т.е. до выхода из OnAllTrade). Какая-то ерунда пока получается с этим переносом обработки таблиц в поток main...

Пытаюсь перенести обработку OnQuote и OnAllTrade в поток main. C OnAllTrade приходит ссылка на таблицу alltrade:Сама таблица alltrade находится в стеке вызова этого коллбэка (очевидно, в стеке тоже ссылка, а сама таблица ещё где-нибудь?)

Если я эту ссылку на alltrade помещу в очередь и выйду из OnAllTrade, то не получится ли так, что после выхода из OnAllTrade эта таблица окажется мусором?

Аналогичный вопрос с OnQuote, которая вызывает getQuoteLevel2 и помещает возвращаемую ей таблицу (ссылку на неё) в ту же очередь для обработки в main.

Мне что, перед выходом из этих функций отключать сборку мусора, а после обработки всей очереди в main опять включать??

В 1-м моём сообщении речь шла о сделках. Ошибочно сделки перетекли в заявки...

С каждой записью в файл утекает ~ 50 байтов памяти, а почему она не собирается сборщиком мусора??

А, ясно, почему такая высокая скорость. А если бы мелкие заявки собирали мелкими, то сервер не успел бы за 1 мкс провести все 339 сделок и образовалась бы очередь?

Это конфиденциальная информация.  

Сегодня наблюдал сабж по некоторой акции на мосбирже с пом. моего скрипта с OnAllTrade. При этом время сделки было то же самое по самую микросекунду. Это произошло сразу после смены цен покупки/продажи. Как такое возможно? Действительно ли эти 339 сделок произошли менее, чем за 1 мкс?

Можно ли где-то получить общее представление о том, как организованы торги на мосбирже и какие там характеристики у серверов (какая ОС, память, ЦП, диски, пропускной канал, ...)? Т.е. как бы совершить виртуальный тур по бирже. Примерно, как в видео на ютюбе о работе tsmc, где клепают лучшие ЦП.

Из аналогичных функций есть ещё
getBuySellInfoEx
CalcBuySell

Мне желательно знать, когда было изменение в стакане, напр., чтобы знать, где я стою в очереди на сделки. Мне кажется, getQuoteLevel2 работает быстро, т.к. эту информацию даёт Квик, который уже получил её с сервера брокера.
К сожалению, квиковцы так и не сделали, чтобы можно было получать через OnQuote или хотя бы getQuoteLevel2 время с сервера биржи, в которое произошло изменение в стакане.

А что же с моим вопросом в #7?

У меня в связи с выносом обработки в main вопрос: напр., я хочу вынести из OnQuote разбор стакана в main, OnQuote будет вызывать getQuoteLevel2 и запоминать результат в циклический массив, а main будет брать его оттуда по текущему индексу, обрабатывать и освобождать память под эту табличку, которую получила через OnQuote от getQuoteLevel2. Не хочется использовать медленные sinsert и sremove. Можно ли сделать такую схему, чтобы не было конфликтов в связи с параллельным использованием данных между потоком main и потоком коллбэков?

Кто знает, сабж для всех инструментов один? Такое впечатление, что нет, сегодня в моём инструменте, по-моему, заявки начали принимать раньше 19:00:01. Возможно, чтобы свои люди, кому хотелось очень продать, встали в очередь пораньше.

Говорят, продают, чтобы купить татнефть(?)

Вот описание SetCell, может, пригодится:

Функция задает значение для ячейки в строке с ключом key, кодом колонки code в таблице t_id. Параметр text задает строковое представление значение параметра value. Параметр value необязательный и по умолчанию равен 0. Для столбцов со строковыми типами данных параметр value не задается. Если параметр value не задан для ячеек всех остальных типов, то по столбцам, содержащим такие ячейки, не будет корректно работать сортировка, фильтрация и условное форматирование (см. Приложение 2). Функция возвращает true в случае успешного завершения, иначе – false.

Формат вызова:
BOOLEAN SetCell(NUMBER t_id, NUMBER key, NUMBER code, STRING text, NUMBER value)

Чтобы от текста для кода функции оставался один заголовой функции.
Наверно, должен быть такой плагин, не могу найти...

Хочу посмотреть пример dll на C, которая обрабатывает коллбэк (напр., OnAllTrade) и для ускорения работы передаёт обработку коллбэка в заранее созданный повторно используемый поток и сразу делает выход. Примеры на C++ не очень интересуют...

И ещё подскажите, в каком потоке работает сборщик мусора? В main, в Квике или в своём собственном? И этот сборщик существует для каждого скрипта свой?

А может быть такое, что Квик что-то меняет в своей таблице, а скрипт в это время читает это поле?
Помню, в районе quik2dde.ru упоминаемый мною kalikazandr писал, что такое возможно, якобы, даже неполный кусок изменяемой Квиком строки можно прочитать. Или это байки алготрейдеров?

Ничего не понятно, но всё так, как надо.  

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

А я вчера много времени потратил на выяснение: будет ли ускорение от такой оптимизации в OnAllTrade и в OnQuote, где вычисляется символьное время сделки/изменения в стакане для вывода типаЧасы и минуты меняются редко, цена и количество акций в стакане по нелучшим ценам тоже: что, если запоминать эти значения в строках, и если они не изменились, вставлять закэшированные?
Мерял время выполнения этих коллбэков через os.sysdate().mcs, получал 0. Снизил частоту ЦП до 800 МГц, внутри коллбэка сделал цикл на 10 повторов, опять 0. Как-то не верится в такое: слишком быстро. А если повтор цикла увеличить, то выскакивают цифры ~ 5000 мкс, 10000, 15500. Про 15500 я знаю, что это квант времени для работы потока. Поэтому я так и не понял, есть ли от этого ускорение. Ведь в этом случае этой оптимизации придётся делать проверки, что время не поменялось, запоминать новое время, конкатенировать строки... В общем, НИР/ОКР ерундой прозанимался...

Кто-нибудь знает, при нескольких конкатенациях:str будет 3 раза удаляться и пересоздаваться, или будет какая-то оптимизация этого присваивания?

Если скрипту давать работать с 10% от депозита, то получится 37% годовых грязными, или 32% чистыми. Если вместо воды пить шампанское, получается не так уж и много...

Когда-то давно в телеграм канале один старый трейдер советовал брать и держать акции сберика, когда одна стоила 132 р., потом когда 137 р., 142 р., т.к. идёт долгострочный тренд с прицелом на ист. максимум. Если бы я послушал его, то сейчас без всяких "ботов" и "стратегий" имел бы 100% годовых чистыми...

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

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

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

Ближайшая задача слегка автоматизировать эту торговлю, чтобы не щёлкать в бешеном темпе по 5-ти стаканам, когда "шара попёрла"...

Кстати, я вчера день потратил на выяснение возможности повторного использования строки и выяснил, что это невозможно, т.к. Луа при малейшей попытке конкатенации моментально отправляет эту строку в мусор, пусть даже её длина равна 0 (очевидно, проверок не делается). Поэтому, надо либо держать строки в массиве и использовать concat, либо в длл.

Когда я это делал, то только начал писать на Луа, не знал, что мне нужно делать, и какая дорога к деньгам более прямая. Просто хотел накопить таких файлов и попробовать найти закономерности взлёта цены. И у меня околонаучный склад ума, как у киплинговского слонёнка: хочется копать вглубь и искать там золотые самородки. До сих пор ничего роботоподобного не сделал...
На этом форуме могут до кровохарканья обсуждать двойные и тройные очереди, показывать загадочные картинки, от которых рябит в глазах, но ничего действительно полезного не скажут.

Тогда посмотрите на кусочек от вывода моего Луа скрипта, который обрабатывал OnAllTrade от 4 января 2023 г.:

Скрытый текст
TRMK 18:45:26.000085 216.96 2 S TRMK 18:45:26.000085 216.96 8 S TRMK 18:45:26.000085 216.96 2 S TRMK 18:45:26.000085 216.96 18 S TRMK 18:45:26.000085 216.96 51 S TRMK 18:45:26.000085 216.96 9 S TRMK 18:45:26.000085 216.96 4 S TRMK 18:45:26.000085 216.96 1 S TRMK 18:45:26.000085 216.96 47 B

Он записывал из таблицы, переданной ему, тикер, время, цену, количество лотов и направление сделки. И таких строк с тем же самым тикером и временем набралось 58. И это только по одному тикеру, а ещё работал обработчик OnQuote, который в этот же файл выводил содержимое стаканов.
Вот ещё кусочек из того же файла, со стаканами:

Скрытый текст

UNAC 09:50:08.180875 bids=10 1.3400/7 1.3350/7 1.3300/7 1.3270/1 1.3250/7 1.3200/10 1.3150/10 1.3100/10 1.3050/10 1.3005/3 offers=13 1.3900/3 1.3950/3 1.4000/2 1.4050/2 1.4100/2 1.4140/1 1.4150/2 1.4200/2 1.4250/2 1.4300/2 1.4350/2 1.4400/2 1.4450/2 IRKT 09:50:08.305869 bids=8 70.30/6 68.95/1 68.25/3 65.70/16 65.00/1 64.35/20 64.00/1 63.30/1 offers=12 70.70/2 71.00/1 71.35/3 71.40/33 72.00/1 73.00/1 73.20/1 73.85/20 74.00/1 75.00/14 76.55/3 77.00/50 NKHP 09:50:08.368363 bids=4 990.0/1 982.5/5 926.0/1 920.0/1 offers=8 1030.0/1 1040.0/1 1050.0/2 1060.0/1 1062.5/1 1065.0/1 1070.0/1 1080.0/1 NAUK 09:50:08.368363 bids=16 541.0/1 540.0/1 539.0/1 537.0/1 535.0/1 533.0/1 531.0/1 529.0/1 527.0/1 525.0/1 523.0/1 521.0/1 519.0/1 517.0/1 515.0/1 490.5/1 offers=17 557.0/1 558.0/1 559.0/1 560.0/1 561.0/1 563.0/2 565.0/1 567.0/1 569.0/1 571.0/1 572.0/1 573.0/1 575.0/1 577.0/1 580.0/1 585.0/1 590.0/1 CNTL 09:50:08.368363 bids=8 16.54/3 16.20/10 16.10/1 16.00/10 15.84/16 15.80/10 15.72/4 15.60/10 offers=15 16.50/50 16.52/1 16.56/2 16.70/2 17.00/5 17.18/80 17.20/6 17.24/25 17.28/10 17.40/1 17.50/100 17.62/19 17.80/1 17.92/3 18.10/1 VRSBP 09:50:08.368363 bids=2 147.0/1 145.0/1 offers=10 159.0/1 161.0/1 163.0/1 165.0/1 167.0/1 168.0/1 169.0/1 170.0/1 171.0/1 172.0/1 KTSBP 09:50:08.368363 bids=1 0.8800/1 offers=2 0.9750/1 1.0000/1 UWGN 09:50:08.368363 bids=20 49.5/285279 49.0/50 48.8/30 47.8/665 47.0/2890 46.9/550 46.3/6500 46.1/2000 46.0/55100 45.9/500 45.5/6490 45.4/17284 45.3/5571 45.2/205205 45.1/131229 45.0/38741 44.9/3048 44.8/3701 44.7/2621 44.6/6346 offers=20 45.0/200 45.1/120 45.2/750 45.4/74 45.5/86 45.7/5 45.8/401 45.9/200 46.0/5270 46.2/5 46.3/200 46.5/163 47.0/517 47.1/128 47.2/203 47.3/506 47.4/102 47.5/21 47.6/1100 47.7/35 KRSB 09:50:08.368363 bids=2 16.48/2 16.00/1 offers=12 17.08/3 17.18/3 17.28/3 17.38/3 17.48/3 17.58/3 17.68/3 17.78/3 17.88/3 17.98/3 18.08/2 18.18/2 NFAZ 09:50:08.368363 bids=18 497.0/1 496.0/1 495.0/1 494.0/1 493.0/1 492.0/1 491.0/1 490.0/1 489.0/1 487.0/1 485.0/1 483.0/1 481.0/1 480.5/10 480.0/1 479.0/1 477.0/1 475.0/1 offers=14 509.0/1 511.0/1 513.0/1 515.0/1 517.0/1 519.0/1 521.0/1 523.0/1 525.0/1 530.0/1 535.0/1 540.0/1 545.0/1 550.0/1 UNAC 09:50:08.368363 bids=10 1.3400/7 1.3350/7 1.3300/7 1.3270/1 1.3250/7 1.3200/10 1.3150/10 1.3100/10 1.3050/10 1.3005/3 offers=14 1.3850/5 1.3900/3 1.3950/3 1.4000/2 1.4050/2 1.4100/2 1.4140/1 1.4150/2 1.4200/2 1.4250/2 1.4300/2 1.4350/2 1.4400/2 1.4450/2 NKHP 09:50:08.493353 bids=6 990.0/1 982.5/5 935.0/1 926.0/1 920.0/1 910.0/1 offers=8 1030.0/1 1040.0/1 1050.0/2 1060.0/1 1062.5/1 1065.0/1 1070.0/1 1080.0/1 YKEN 09:50:08.493353 bids=1 0.5950/10 offers=1 0.6980/1 DZRD 09:50:08.493353 bids=13 4285/3530 4280/50 4200/6 4000/1 3910/1 3905/2 3900/13 3895/1 3800/1 3750/1 3560/16 3555/9 3550/4 offers=1 3965/1 RUSI 09:50:08.493353 bids=3 107.0/5 106.0/5 105.6/3 offers=8 113.0/5 114.0/5 115.0/5 116.0/5 117.0/5 118.0/5 119.0/5 120.0/5 UWGN 09:50:08.493353 bids=20 49.5/285279 49.0/50 48.8/30 47.8/665 47.5/7500 47.0/2890 46.9/550 46.3/6500 46.1/2000 46.0/55100 45.9/500 45.5/6490 45.4/17284 45.3/5571 45.2/206205 45.1/131229 45.0/38841 44.9/3048 44.8/3701 44.7/2621 offers=20 45.0/200 45.1/120 45.2/750 45.4/74 45.5/86 45.7/5 45.8/401 45.9/200 46.0/5270 46.2/5 46.3/200 46.5/163 46.8/19 47.0/536 47.1/128 47.2/203 47.3/506 47.4/102 47.5/21 47.6/1100 IGST 09:50:08.493353 bids=8 10850/1 10800/1 10750/1 10700/1 10650/1 10500/2 10200/1 10100/1 offers=5 11650/1 11670/1 11700/1 11780/1 11950/1 RTSBP 09:50:08.493353 bids=6 1.410/1 1.400/2 1.390/2 1.380/2 1.370/2 1.360/2 offers=6 1.510/1 1.530/1 1.550/1 1.558/1 1.570/1 1.600/1 RTSB 09:50:08.493353 bids=7 3.700/1 3.650/1 3.625/1 3.600/1 3.575/1 3.550/1 3.525/1 offers=2 3.900/1 3.950/1 DZRDP 09:50:08.493353 bids=10 3930/10 3880/33 3870/4 3850/1 3730/8 3710/1 3700/1 3690/1 3580/61 3570/1 offers=8 3980/1 4080/1 4100/1 4110/1 4140/1 4180/10 4190/79 4200/2 IGSTP 09:50:08.493353 bids=7 7920/5 7800/1 7700/1 7600/1 7500/1 7400/1 7350/1 offers=4 8300/1 8630/1 8700/1 8900/1 NKHP 09:50:08.618344 bids=6 990.0/1 982.5/5 935.0/1 926.0/1 920.0/1 910.0/1 offers=9 1030.0/1 1040.0/1 1050.0/2 1060.0/10 1062.5/1 1065.0/1 1070.0/1 1080.0/1 1098.0/5

В OnAllTrade видел: время на сервере биржи с точностью 1 мкс не меняется, а в файл записалось больше 64 сделок...

Можно найти, что эта тема (чудовищная конкатенация строк в Луа) волнует народ в районе англоязычного stackoverflow, а здесь создатель Луа предлагает такую полумеру: https://www.lua.org/pil/11.6.html

И да, ваш перегруженный вариант анекдота некорректен: ведь я с самого начала играл на стороне чукчи...

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

И всё-таки, я на этом форуме несколько раз видел, что людям издавна не хватает скорости (и для них это "жизненно важно"), а наращивание числа ядер и повышение тактовой частоты мало что не даёт, вот ещё пример такой темы: https://forum.quik.ru/forum10/topic3872/

А геологам просто надо держать свои снегоходы заведёнными.

Мне кажется, что ничего не случится, если извне (из длл) строка будет изменена, ведь, если строка не находится внутри таблицы, вычисление хеша от неё не нужно?

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

Вопрос, почему mciSendString в консольной программе не выдаёт звук, так и остался открытым...

Не нашёл нормального "линтера", а условный оператор это не совсем то и громоздко...