d'Ivan

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

throttle / debounce

Что это вообще такое?
Троттлинг функции означает, что функция вызывается не более одного раза в указанный период времени (например, раз в 10 секунд). Другими словами ― троттлинг предотвращает запуск функции, если она уже запускалась недавно. Троттлинг также обеспечивает регулярность выполнение функции с заданной периодичностью.

Debouncing функции означает, что все вызовы будут игнорироваться до тех пор, пока они не прекратятся на определённый период времени. Только после этого функция будет вызвана. Например, если мы установим таймер на 2 секунды, а функция вызывается 10 раз с интервалом в одну секунду, то фактический вызов произойдёт только спустя 2 секунды после крайнего (десятого) обращения к функции.

https://www.google.com/search?q=js+throttle+debounce
https://medium.com/nuances-of-programming/%D1%87%D...

Это называется кластеризация. Вам надо разбить данные на 3 кластера. Метод ближайших соседей, упомянутый выше, подходит.

Все-таки все эти методы кластеризации разработаны для более общего случая. А у вас тут данные одномерные и численные уже - так что все совсем просто.

Во-первых, данные надо отсортировать, если уже не. А дальше у вас тут 2 переменные - (i,j) - первый и последний элемент в средней группе.i>0,j<n-1.

Можно эти индексы тупо перебрать двумя вложенными циклами. А дальше надо считать какую-то целевую функцию - насколько хорошо кластеры выбраны и брать лучшее значение. Надо, чтобы внутри различие было поменьше, а между кластерами - побольше. Можно брать максимум разности в каждом кластере и делить на разницу между двума кластерами. Вот минимизируйте эту функцию.

Но вообще можно, наверно, просто взять 2 максимальных промежутка между соседними числами и по ним разделить. В примере выше этот метод отлично разбивает на 3 группы: 1-103, 999-1001, 9000-9500

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

let [dataRu,dataEn] = await Promise.all([getProductsDataRu(urls),getProductsDataEn(urls)])

зачем там реализуют разные модули, типа кеша, вроде в каком-то даже увидел конвеер исполнения команд, предсказатели переходов. И прочие. К примеру кеш, тлб, зачем он там нужен. если все как бы просиходит внутри машины?

Фронт-енды QEMU реализуют большую часть наблюдаемого поведения моделируемого ими процессора. Одно большое исключение -- это процессорный кеш: QEMU не моделирует поведение процессорного кеша. TLB во многих архитектурах доступен для прямого чтения/записи через команды процессора, нельзя сказать что он "внутри машины".

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

Покажи пример, обсудим конкретику?

Ассоциативная память. Если там внутри делается таблица адресов, виртуальных адресов. То к примеру для адресного пространства 4гб, будет 2^32 это будет в 32 раза дольше.

Это какие-то очень странные допущения и прикидки, а то, что они не учитывают такие параметры как размер TLB и его ассоциативность, показывает их безосновательность.

Короче, в итоге для поиска адреса в супер жесткой виртуальной машине, будет до 32 операции сравнений по словарю, потом суммарно где же в кешах каждого уровня, куча прочих проверок .... .

Нифига. В QEMU есть два уровня TLB -- один, моделируемый процессорным фронт-ендом, второй -- собственный TLB QEMU softmmu независимый от эмулируемого процессора, поиск по которому встроен в генерируемый JIT (который в QEMU называется TCG) код. Собственный TLB QEMU прямого отображения, т.е. поиск в этом TLB -- это всегда проверка одного элемента массива и загрузка одного отображения в случае успеха. Например вот так генерируется код для этого на хосте x86. В случае неудачи происходит вызов функции поиска в архитектурно-зависимом TLB. Вот так этот вызов генерируется, а вот пример его реализации во фронт-енде. Поскольку этот TLB моделирует конкретную архитектуру его ассоциативность может варьироваться в широких пределах, или он может вообще отсутствовать. В случае промаха или отсутствия TLB поиск может либо продолжаться дальше в таблицах страниц, например так, либо фронт-енд генерирует исключение доступа к памяти, например так.

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

Как-то так

хватит школьных знаний

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

Идея простая.
Асинхронные приложения - это набор пар "операция - обработчик", где операция - это некоторый длительный процесс (скажем, вводы/вывод), который не требует постоянного внимания со стороны кода. Когда операция завершается, выполняется её обработчик. Этот обработчик может планировать другие операции, и так далее.

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

Соответственно, await-вызов сохраняет текущий контекст корутины, и планирует новую длительную операцию. Какую - зависит от того, что идёт после await. Эта операция представлена тем или иными awiatable значением (Future, Task и т.п.).

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

Ключевой момент - выполняет обработчик, а только потом проверяет остальные операции. Т.е. если обработчик планирует операцию через await - это не проблема, она будет выполняться наравне с остальными. А вот если обработчик просто делает что-то длительное, он не возвращает управление циклу, и не даёт выполняться остальным операциям.

asyncio.sleep() планирует ничего не делающую операцию, которая завершится успехом через заданное время. Поэтому её выполнение не мешает циклу-реактору. Просто ещё один await вызов, который приостанавливает текущую корутину и возвращает управление реактору.

time.sleep() ничего не знает о реакторе и асинхронных операциях. Она приостанавливает выполнение обработчика, не прерывая его и не отдавая контроль реактору. Поэтому на время time.sleep() (или любой длительной синхронной операции) спит вся программа.