Потоки для оптимизация сериализации нескольких данных

@Passerby · Регистрация: 22.09.2017

Студворк — интернет-сервис помощи студентам

4-х ядерный проц i5 7500. Программа собирает данные от 5 источников по сети и регулярно сбрасывает их на диск. С учетом того, что записывается время опроса данных получается 5 словарей, в каждом словаре разные данные по своему источнику в сети + один List<DateTime>. Как лучше сериализовать эти данные? Вариант 1. На каждый словарь и на лист сделать отдельный поток. и дожидаться окончания всех потоков Но т.к. потоков должно быть 6 (5+1) не будет ли в этом случае переключения потоков с одной незаконченной задачи на другую и на это будет теряться время. Или лучше сделать 4-е потока, подождать их окончания, т.е. записи на диск, а затем сделать еще два потока? Во время сериализации и записи на диск желательно, чтобы как на можно меньшее время прерывался сбор данных с источников в сети. Архивация в gzip приводит к большей потере времени на запись. Сейчас без потоков запись идет примерно 5 сек.

Добавлено через 13 минут
Объем данных от разных источников разный и заранее известно, где объем большой, а где нет.

@freeba · 26.04.2019, 06:05

База данных в помощь.

@Элд Хасп · 26.04.2019, 12:16

Сообщение от Passerby

Как лучше сериализовать эти данные?

От количества потоков скорость сериализации не вырастет. Сериализация - это ПОСЛЕДОВАТЕЛЬНАЯ запись объекта в файл. По своей сути работа с диском - это тоже последовательный механизм. Поэтому последовательная запись 6 файлов, всегда будет как минимум не медленнее записи каждого из этих файлов в отдельном потоке. А на практике для HDD, обычно, многократно быстрее.

Если Вам надо освобождать потоки для обработки следующей порции данных. То разделите обработку данных и их сохранение. Обрабатываются пусть в параллельных потоках, а сохраняются в последовательных.

@Passerby · 26.04.2019, 19:02 **[ТС]**

Сообщение от freeba

База данных в помощь.

Сохранение в базе данных с записью на диск будет быстрее сериализации? За счет чего?

Сообщение от Элд Хасп

От количества потоков скорость сериализации не вырастет. Сериализация - это ПОСЛЕДОВАТЕЛЬНАЯ запись объекта в файл. По своей сути работа с диском - это тоже последовательный механизм. Поэтому последовательная запись 6 файлов, всегда будет как минимум не медленнее записи каждого из этих файлов в отдельном потоке. А на практике для HDD, обычно, многократно быстрее.

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

@Diamante · 27.04.2019, 00:10

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

Новые блоги и статьи Все статьи Все блоги /
Валидация и контроль данных табличной части документа перед записью Maks 22.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа, разработанного в КА2. Задача: контроль и валидация данных табличной части документа перед записью с учетом регламента компании. . .	Отчёт о затраченных материалах за определенный период с макетом печатной формы Maks 21.04.2026 Отчёт из решения ниже размещён в конфигурации КА2. Задача: разработка отчёта по затраченным материалам за определённый период, с возможностью вывода печатной формы отчёта с шапкой и подвалом. В. . .	Отчёт о спецтехнике находящейся в ремонте Maks 20.04.2026 Отчёт из решения ниже размещен в конфигурации КА2. Задача: отобразить спецтехнику, которая на данный момент находится в ремонте. Есть нетиповой документ "Заявка на ремонт спецтехники" который. . .	Памятка для бота и "визитка" для читателей "Semantic Universe Layer (Слой семантической вселенной)" Hrethgir 19.04.2026 Сгенерировано для краткого описания по случаю сборки и компиляции скелета серверного приложения. И пусть после этого скажут, что статьи сгенерированные AI - туфта и не интересно. И это не реклама -. . .
Запрет удаления строк ТЧ документа при определённом условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .

@Passerby -7 / 3 / 1 Регистрация: 22.09.2017 Сообщений: 242

	Потоки для оптимизация сериализации нескольких данных 25.04.2019, 23:57. Показов 1175. Ответов 4 Метки нет (Все метки) 4-х ядерный проц i5 7500. Программа собирает данные от 5 источников по сети и регулярно сбрасывает их на диск. С учетом того, что записывается время опроса данных получается 5 словарей, в каждом словаре разные данные по своему источнику в сети + один List<DateTime>. Как лучше сериализовать эти данные? Вариант 1. На каждый словарь и на лист сделать отдельный поток. и дожидаться окончания всех потоков Но т.к. потоков должно быть 6 (5+1) не будет ли в этом случае переключения потоков с одной незаконченной задачи на другую и на это будет теряться время. Или лучше сделать 4-е потока, подождать их окончания, т.е. записи на диск, а затем сделать еще два потока? Во время сериализации и записи на диск желательно, чтобы как на можно меньшее время прерывался сбор данных с источников в сети. Архивация в gzip приводит к большей потере времени на запись. Сейчас без потоков запись идет примерно 5 сек. Добавлено через 13 минут Объем данных от разных источников разный и заранее известно, где объем большой, а где нет. 0

@freeba Неадекват 1501 / 1237 / 248 Регистрация: 02.04.2010 Сообщений: 2,807
	26.04.2019, 06:05
	База данных в помощь. 1

@Diamante 3566 / 2507 / 1174 Регистрация: 14.08.2016 Сообщений: 8,219
	27.04.2019, 00:10
	может стоит копнуть в сторону необходимого кол-ва слушателей, которые, по мере получения данных, передают их "писателю", который или копит данные и потом скопом пишет(диск, сеть, бд, файл, перфокарты, манускрипты) или пишет сразу? 1

Опции темы