ну да, не сама - это понятно

ну т.е. если конец функции - конец обслуживания запроса клиента, то всё ровно? содержимое res копирнется до переключения на другой файбер?

ага, мы даже где-то это использовали. Но тут одна ошибка и ты ошибся, очень опасная оптимизация

а детали какие-нибудь? :)

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

В целом, я бы предложил использовать require "table.new" -- он позволяет аллоцировать сразу необходимое количество слотов в таблице, чтобы избежать реаллокаций, и, возможно, если очень-очень нужно, пул таблиц, которые очищаются при возврате в пул.

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

спасибо

Схема на mysql меня устраивает всем, кроме быстро действия. При работе в 20 потоков база начинает жутко тормозить. В памяти данные или на жёстком диске не критично лишь бы работало

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

Часто меняются битовые маски, числовое поле grow и строковое list

Приложение написано на C?

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

20 потоков на запись или на чтение? Как распределяется нагрузка на чтение и запись?

Запись / Чтение = 50 / 50

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

Тогда write-behind

Для такого использования можно реализовать операции перемещения данных на нижние слои, работать с данными непосредственно в тарантуле + в процессе перемещения будет происходить вытеснение в MySQL + read-through кэш для данных с нижних уровней, к которым идёт частое обращение

Спасибо. Возможно это то, что мне нужно. Попробуй почитать подробеее.

Я плох в сравнениях БД, но точно ли тарантул тут нужен? Может другие какие-то, как я понимаю это не принципиально

Окей, какие есть варианты?

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