mayton2019

Работает другая ветка "if"

Несколько мыслей.

1. In-memory базы данных будут медленнее чем C# структуры данных. Им ведь надо перекидывать данные через границу процесса. Память не шарится соотв - сериализация-сетевые сокеты пускай даже локальные. Все это будет медленнее.

2. Я не знаю ни одной структуры данных которая-бы себя хорошо вела при конкуретнтной вставке. Concurrent - коллекции нужно только в том случае когда результат вставки в ту-же милисекунду нужен вам на чтение как результат из другого потока. Это очень строгое требование и реально очень мало систем им обладают. Я-бы предложил следующее. Если 5 потоков пишут независимо без обратной связи - то пускай пишут в буферы в несколько килобайт. И пускай 6 поток периодически собирает эти буферы. Так можно уменьшить конкуренцию. Лаг можно регулировать. Сколько хотим? 10 мс? 100мс?

Еще вариант - потоки пишут каждый в свой Dictionary. И периодически происходит merge. Пакетом. Тут надо померять performance. Вообще в конкурирующих работах с key-value ищут возможность сделать partitioning. Если удасться то будут конкурировать максимум 2 потока а не 5.

Есть такая легаси штука как transfer mode. По умолчанию он может быть ascii и для бинарных файлов может быть какая-то фигня после передачи. Лучше сразу после подключения к серверу включить binary mode. На всякий случай.

Вообще подключись консолью и посмотри размер файла.

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

Мне кажется что ничего не нужно парсить. Можно создать интерфейс графа поверх лабиринта.
Вершины есть. Ребра есть. Все готово для поиска путей и доказательства достижимостей.

Можно только добавить дополнительно на все ребра и вершины возможность ставить метки.
Это как раз для графовых алгоритмов.