Д
Без какой повязки
Size: a a a
2020 March 17
Д
С символом партии?
I
вопрос на засыпку: у меня есть парсер лога, он написан давно на c# (я вот на днях переписал на f#). Там единственное что мне не нравится, что он написан полностью на синхронных функциях. Но если я пробую разные варианты асинхронности, то производительность сразу в разы падает. Вообще это переписывание не имеет никакого смысла (т.к. это часто консольная утилита), но меня периодически мучает этот вопрос. Есть пример, где парсят логи асинхроно? ПРоблема в том, что логов может быть больше чем помещается в память, поэтому надо парсить потоком и тут же обрабатывать
AH
Igor
вопрос на засыпку: у меня есть парсер лога, он написан давно на c# (я вот на днях переписал на f#). Там единственное что мне не нравится, что он написан полностью на синхронных функциях. Но если я пробую разные варианты асинхронности, то производительность сразу в разы падает. Вообще это переписывание не имеет никакого смысла (т.к. это часто консольная утилита), но меня периодически мучает этот вопрос. Есть пример, где парсят логи асинхроно? ПРоблема в том, что логов может быть больше чем помещается в память, поэтому надо парсить потоком и тут же обрабатывать
парси асинхронно через очередь. Из очереди выгребай чанками в выделенный тред парсера
AH
сделай там лингеринг - или ожидание 50мс или если в чанк прилетело 1000 записей.
далее выгребаешь 1000 записей и парсишь, берёшь следующий чанк...
далее выгребаешь 1000 записей и парсишь, берёшь следующий чанк...
I
да там формат говняный, пока нераспарсишь, непонятно где заканчивается одна запись и начинается другая
AH
да один хер
AH
тогда выгребай по символам, строкам я хз
AH
у тебя будет остаток в парсере - недопаршенное с прошлого чанка
AH
который надо будет приклеить в начало следующего
I
у тебя будет остаток в парсере - недопаршенное с прошлого чанка
вот с этим как раз проблема, потому что если текущий чанк закончился, то нужно await следующий чанк и получается что все функции становятся асинхронными и накладных расходов очень много
AH
Тут чот не то. У тебя парсер все ещё синхронный, у тебя лог асинхронно пополняется
AH
То есть клиент не блокируется на логе.
AH
А вот парсер очень даже блокируется
DS
Igor
вот с этим как раз проблема, потому что если текущий чанк закончился, то нужно await следующий чанк и получается что все функции становятся асинхронными и накладных расходов очень много
Имхо, если там именно что поточное чтение, то вряд ли имеет смысл делать асинхронность.
Так и так упрешься в чтение с диска
Так и так упрешься в чтение с диска
С
Интересная аномалия в этом году
А есть стата смертности от этого орви
I
у тебя будет остаток в парсере - недопаршенное с прошлого чанка
А кажется я понял, нужно инвертировать процесс, сейчас у меня парсер вытягивает данные из файла, а надо наоборот пропихивать в парсер. Т.е. читать чанк из файла и передавать его в парсер, парсер возвращает записи, которые он распарсил и остаток, который не смог распарсить. Потом этот остаток дополнить очередным чанком и т.д.
I
Имхо, если там именно что поточное чтение, то вряд ли имеет смысл делать асинхронность.
Так и так упрешься в чтение с диска
Так и так упрешься в чтение с диска
Думал чтобы все ядра загрузить по полной, чтобы сразу много файлов парсить параллельно
IC
Хм, похоже на меилбоксы!