[Forger 26]

22 minutes ago, jcxz said:

Динамическое выделение не увеличивает размер доступной ОЗУ в МК.

Если это шутка, то она неуместная. 

Само собой должно проверяться ограничение на максимальный размер json (и не только это).

 

Суть экономии в том, что при старте выделяем память под весь json файл, парсим его, определяя сколько места нужно под уже перекодированный (назовем бинарный) файл и выделяем под него место.

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

Таким образом как раз экономится драгоценное внутреннее ОЗУ, т.к. кусок, занятый под текстовый json, высвобождается.

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

 

[jcxz 241]

5 часов назад, Forger сказал:

Суть экономии в том, что при старте выделяем память под весь json файл, парсим его, определяя сколько места нужно под уже перекодированный (назовем бинарный) файл и выделяем под него место.

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

Непонятно что такое "json-файл"? Причём тут какой-то "файл" если JSON-сообщение приходит по каналу связи. Вы что - предлагаете его сначала куда-то сохранить в файловую систему, а затем парсить из этого текстового буфера в другой - бинарный вид???   Так это вообще бессмысленное разбазаривание памяти. Место под текстовый JSON (размер которого неизвестен) + место под бинарный + ещё место под какие-то "модули". Плюс - зачем-то создавать только для этого файловую систему. Плюс - выделение/освобождение дин.памяти, после нескольких итераций которого память фрагментируется и потом её вообще не хватит на последующие JSON.

И к тому же - как вы при старте выделите "память под весь json файл" если заранее неизвестен размер входящего JSON?

У меня принимамый JSON сразу, на лету парсится в бинарный вид. В один единственный буфер. В котором затем обрабатывается. Без всяких промежуточных буферов, динамических аллокаций/освобождений и прочей ненужной шелухи.

Такой монстр, какого вы описываете, терпим только на ПК или если памяти вагон + тележка. А на рядовом МК это бесмысленная трата ресурсов памяти. 

5 часов назад, Forger сказал:

Таким образом как раз экономится драгоценное внутреннее ОЗУ, т.к. кусок, занятый под текстовый json, высвобождается.

В чём "экономия"??? Хоть убейте не пойму.  Описываете тупое в лоб решение, которым можно идти только если памяти немеряно. И которое потребует в разы больше ОЗУ, чем моё решение.

Или я вообще не понял о чём вы писали.......

[Forger 26]

1 hour ago, jcxz said:

затем парсить из этого текстового буфера в другой - бинарный вид???

Для более быстрого доступа к параметрам из json по ходу работу приложения. В настоящее время из-за недетеминированности времени доступа к отдельным параметром к ним приходится обращаться только при старте приложения еще до разворачивания системы.

Использование промежуточного формата позволит этого избежать.

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

 

2 hours ago, jcxz said:

Плюс - зачем-то создавать только для этого файловую систему.

FS используется далеко не для только для хранения json-файла, там хранятся виджеты (картинки, шрифты), прошивки, документация.

В этом проекте у меня все юзер-файлы хранятся на флэшке, распаянной на плате (16...64Мб).

 

2 hours ago, jcxz said:

плюс - выделение/освобождение дин.памяти, после нескольких итераций которого память фрагментируется

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

Используется куча на базе TLSF, она имеет некоторый оверхед для обслуживания (около 3кб), но за счет схемы построения с фрагментацией там дела обстоят значительно лучше.

Кому любопытно исходники и описание есть гитхабе. 

 

2 hours ago, jcxz said:

И к тому же - как вы при старте выделите "память под весь json файл" если заранее неизвестен размер входящего JSON?

Файл 'не входит" по некому каналу, он доступен весь с любого места, т. к. хранится на флэшке:

FILE * file = fopen(settingsFileName, "rb");
if (file == NULL) ....

fseek(file, 0, SEEK_END);
settingsSize = ftell(file);
settingsBuffer = static_cast<char*>(malloc(settingsSize));
if (settingsBuffer == nullptr) ....

 

2 hours ago, jcxz said:

Или я вообще не понял о чём вы писали.......

Судя по всему ))

У меня файлы не приходят "по воздуху", другая задача. Все файлы сразу доступны приложению с внутренней флэшки.

[x893 60]

Бессмысленный спор. Реализация зависит от задачи, которая решается.

[Forger 26]

9 minutes ago, x893 said:

Бессмысленный спор. Реализация зависит от задачи, которая решается.

Тут нет спора, у каждого действительно свои задачи. Мне же лишь приглянулась идея с промежуточным разбором json полей, это позволяет решить мне две задачи разом: расход ОЗУ и возможность одинаково быстро извлекать использовать любой параметр по ходу работы приложения.

Вероятно, мы просто не поняли друг друга (тут это типично).

[turnon 1]

10 hours ago, Forger said:

Кстати, ваша идея с предварительным разбором json в более быстрочитаемый формат мне кажется полезной.

Да, для удобной работы с JSON в программе нужны или объекты при ООП, или структуры как у @jcxz

9 hours ago, x893 said:

Ну это давно используется. Кавычки можно для экономии выкинуть. Есть варианты ещё короче сделать описание, использовав бинарные данные.

Так это уже будет не JSON. Сейчас модный JAML.

8 hours ago, Forger said:

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

Именно из-за этого и использую парсеры, которые ничего не создают в памяти, а проходят весь файл по запросу ("JSON PATH"), сейчас использую coreJSON, ранее mjson (страшненький внутри и есть баги). А дин. память я лучше отдам реальным объектам, а не какому-то JSON'у.

Тем более что в реальном объекте представление может быть компактнее, а не прямым отображением JSON'а. Например, IP-адрес из строки вида "192.168.0.1" - в объекте это 4 байта, а не 15.
Пример конечно синтетический, но суть отображает.

[Forger 26]

48 minutes ago, turnon said:

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

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

А ведь действительно!, можно предварительно пропарсить весь файл попутно вычитывая из него кусками побайтно, выяснив таким образом сколько памяти нужно на промежуточный формат (внутри это будет банальный по сути массив).

Потом выделить память под этот промежуточный "массив" и заново пропарсить файл, уже заполняя этот массив данными.

Тогда не придется выделять память под сам json-файл!

 

[xvr 12]

Всё придумано до нас:

http://bjson.org/

https://developers.google.com/protocol-buffers

И не надо велосипеды изобретать

 

 

[turnon 1]

57 minutes ago, xvr said:

Всё придумано до нас:

http://bjson.org/

https://developers.google.com/protocol-buffers

И не надо велосипеды изобретать

Поделитесь впечатлениями, где и как давно применяете, какие достоинства/недостатки?

[Forger 26]

1 hour ago, xvr said:

Всё придумано до нас:

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

[xvr 12]

6 hours ago, turnon said:

Поделитесь впечатлениями, где и как давно применяете, какие достоинства/недостатки?

В мою бытность работы в Яндекс насмотрелся на оба формата. Первый закапывали, переходили на второй. BSON в частности применяется в MongoDB

Protobuf применялся повсюду (я работал в Картах, у них для связи клиентской программы и бэкэндов везде он). Из преимуществ автоматические биндинги в любые языки программирования и возможность делать расширения уже существующих протоколов в back compatible виде (но это не автоматом - требуется тщательное ручное вмешательство)

Ну и стандартизированное описание форматов.

[Solonovatiy 0]

On 12/8/2022 at 11:15 PM, std said:

Строки и сериализация? Вряд ли.  (полагаю у вас Javascript прошлое и отсюда такие идеи).
Самое простое для вас это ознакомиться с реализацией сообщений в WinAPI, AmigaOS или погуглить "osCreateMesgQueue".   (чистый C).

А, ну если кто-то хочет сильно понятный код, то он обязательно жабсер (ведь на жабсе все так понятно), настоящие си-деды принимают только полностью нечитаемое месиво состоящее из 3х приведений void* в одной строке. ЖС с Си в этом похожи, типов нет считай = ) Просто в одном из них, можно точку запятой не ставить.

Я не понял принципиального отличия очередей обычных от сообщений этих. Предполагаю, что у сообщений может быть куча ресиверов? Если нет, то это те же очереди, только в профиль, а если да, то какой-то сорт сокетов но кусками уже. 

>>> Сериализация

А как вы еще будете кидаться данными между двумя модулями?

Если один знает о другом, на кой черт, ему не типизированное АПИ, что бы точно, где накосячить?
Если они не должны ничего знать - значит у вас некие данные-обобщения уже гоняются и дефакто конвертируются\адресуются. 

То что вы сказали ВОТ ЕСТЬ СООБЩЕНИЯ - не хрена не объясняет методы их использования. Ну есть. Ок. Можно межпотоком бинарным массивов кинуться. Это в заголовке ОП поста было. 

 

 

 

[turnon 1]

14 hours ago, xvr said:

Protobuf применялся повсюду (я работал в Картах, у них для связи клиентской программы и бэкэндов везде он). Из преимуществ автоматические биндинги в любые языки программирования и возможность делать расширения уже существующих протоколов в back compatible виде (но это не автоматом - требуется тщательное ручное вмешательство)

А из недостатков?

[xvr 12]

1 hour ago, turnon said:

А из недостатков?

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

Второе уже упоминал - ручное отслеживание backward compatible изменений (если они нужны).

В остальном одни плюсы