Перейти к содержанию
    

Архитектура программ во встраиваемой электронике

22 minutes ago, jcxz said:

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

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

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

 

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 minutes ago, x893 said:

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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.
Пример конечно синтетический, но суть отображает.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

48 minutes ago, turnon said:

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

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

http://bjson.org/

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

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

57 minutes ago, xvr said:

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

http://bjson.org/

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, xvr said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 hours ago, turnon said:

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

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

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

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

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

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

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

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 hours ago, xvr said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, turnon said:

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

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

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

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

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...