[tgruzd 11]

Хорош

[Forger 24]

5 minutes ago, tgruzd said:

Хорош

опять никакой конкретики

засчитано

[tgruzd 11]

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

под этом вашим новым термином: сломался "формат файла"?

Да, я выразился неправильно. Но полагаю, вы поняли о чем речь)

[Forger 24]

3 hours ago, tgruzd said:

Да, я выразился неправильно.

уже тенденция

 

3 hours ago, tgruzd said:

 

Но полагаю, вы поняли о чем речь)

Нет, я не экстрасенс. С точки зрения файловой системы нет и близко таких понятий. Поэтому и спрашиваю.

[smart_pic 7]

On 11/18/2022 at 12:19 AM, Solonovatiy said:

поговорить о некоторых базовых аспектах архитектуры ПО встраиваемых систем

Сначала определитесь что такое встраиваемые системы.

если это 8 бит контроллер , то и подход к организации хранения данных , ведения логов , файловой системы будет сильно отличать от того, о чем в последних постах пошел разговор. И не нужно натягивать файловую систему ПК на МК, итог уже известен заранее.

 

[jcxz 235]

В 10.12.2022 в 16:47, turnon сказал:

Нашел вот такую штуку - mjson, не требует никаких буферов (ничего не хранит в RAM), для извлечения элемента парсит весь json, но меня это устраивает.

У меня работа с JSON выполняется в 2 этапа:

1. Входящий текстовый JSON парсится (однократно, за один проход) в бинарный вид. В бинарном виде каждый элемент JSON занимает фиксированный размер. Строковые идентификаторы заменяются на их индексы в const-таблице.

2. Выполняется содержательная обработка элементов JSON из бинарного образа. Как последовательная (сразу за один проход все элементы); так и произвольная - с поиском обрабатываемого элемента с обходом по дереву вложенности JSON-объектов/массивов. Такой поиск по бинарному образу выполняется на порядки быстрее, чем по текстовому исходнику, так как не надо парсить строки/тестовые_записи_чисел и т.п.

Для исходящих JSON аналогичная последовательность: сперва формирование бинарного образа, потом (непосредственно перед отпракой в связной канал) - распечатка этого бинарного образа прямо в TCP/IP-буфер канала связи.

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

[turnon 1]

3 hours ago, jcxz said:

1. Входящий текстовый JSON парсится (однократно, за один проход) в бинарный вид. В бинарном виде каждый элемент JSON занимает фиксированный размер.

Ну мне критично как раз фиксированный размер буфера для неизвестного размера JSON.
 

3 hours ago, jcxz said:

Строковые идентификаторы заменяются на их индексы в const-таблице.

А строковые значения?

[jcxz 235]

45 минут назад, turnon сказал:

Ну мне критично как раз фиксированный размер буфера для неизвестного размера JSON.

Как такое может быть?

45 минут назад, turnon сказал:

А строковые значения?

u8 = {[id], тип_строка, длина_тела_строки, тело_строки}

Точнее даже два разных типа: тип_строка1, тип_строка2 - однобайтовые символы и 2-байтовые. Хотя это уже оптимизация, так как строки в основном 1-го типа и только изредка - 2-го.

[id] - идентификатор, наличие опционально (внутри объектов - есть; внутри массивов - отсутствует).

[turnon 1]

5 minutes ago, jcxz said:

Как такое может быть?

JSON на то и выбрал что расширяется, добавляются новые ветки и т.д. Это промежуточный бинарный формат (что у вас) все равно не целевой, JSON транслируется в объекты программы. Так что мне надежнее всегда иметь фиксированный буфер, поступившись скоростью обработки, скорость мне как раз некритична.

[jcxz 235]

10 минут назад, turnon сказал:

JSON на то и выбрал что расширяется, добавляются новые ветки и т.д. Это промежуточный бинарный формат (что у вас) все равно не целевой, JSON транслируется в объекты программы. Так что мне надежнее всегда иметь фиксированный буфер, поступившись скоростью обработки, скорость мне как раз некритична.

Не очень понятно про фиксированный буфер... Если Вы его не храните, а парсите прямо на лету, во время приёма, то да - буфер вообще не нужен. Но тогда возможен только один проход по JSON-у. А если сохранять, то без разницы в виде текста или бинарном, в любом случае от размера буфера будет зависеть размер максимального обрабатываемого JSON. Только при текстовом сохранении нет твёрдой гарантии, что JSON одного и того же полезного содержимого всегда влезет в выделенный буфер (из-за символов фоорматировани, незначащих нулей в числах и т.п.) А с бинарным хранением - гарантия есть.

[turnon 1]

3 minutes ago, jcxz said:

А если сохранять, то без разницы в виде текста или бинарном, в любом случае от размера буфера будет зависеть размер максимального обрабатываемого JSON.

Я использую ООП, у меня объект инициализируется из JSON. Можно конечно и в бинарном виде, но в этом случае я будут работать не с объектом, а с этим бинарным видом.

[jcxz 235]

Когда я выбирал свой формат, это была одной из главных причин: Если существует некий блок данных, описываемый JSON-ом, и бинарный образ этого JSON влазит в выделенный буфер, то при любом изменении элементов этого блока данных, какое бы ни было применено форматирование при формировании JSON из этого блока данных, бинарный образ однозначно влезет в буфер (строки не учитываем, они у меня использются редко и короткие - просто рассчитываю по максимальной длине для каждой конкретной строки).

Например если есть блок данных, описываемый в программе как:

__packed struct {
  u8 x0;
  u32 y0;
  __packed struct {
    u16 x1;
    u32 y1;
    __packed struct {
      u32 x2;
      u32 y2;
    } d2;
  } d1;
} d0;

из которого формируется JSON:

{
  "x0":1,
  "y0":2,
  "d1":{
    "x1":3,
    "y1":4,
    "d2":{
      "x2":5,
      "y2":6
    } 
  }
}
        

И для хранения его бинарного образа достаточно скажем <=N байт буфера, то какое бы значение не принимали члены этого блока данных, сколько бы незначащих нулей не было в числах, сколько бы пробелов и переводов строк не было внутри текстового JSON; в любом случае - N байт буфера всегда будет достаточно.

[Forger 24]

59 minutes ago, jcxz said:

Только при текстовом сохранении нет твёрдой гарантии, что JSON одного и того же полезного содержимого всегда влезет в выделенный буфер

Есть решение - создавать буфер динамически под размер всего файла json.

 

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

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

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

[x893 51]

1 hour ago, jcxz said:

Когда я выбирал свой формат, это была одной из главных причин: Если существует некий блок данных, описываемый JSON-ом, и бинарный образ этого JSON влазит в выделенный буфер, то при любом изменении элементов этого блока данных, какое бы ни было применено форматирование при формировании JSON из этого блока данных, бинарный образ однозначно влезет в буфер (строки не учитываем, они у меня использются редко и короткие - просто рассчитываю по максимальной длине для каждой конкретной строки).

Например если есть блок данных, описываемый в программе как:

__packed struct {
  u8 x0;
  u32 y0;
  __packed struct {
    u16 x1;
    u32 y1;
    __packed struct {
      u32 x2;
      u32 y2;
    } d2;
  } d1;
} d0;

из которого формируется JSON:

{
  "x0":1,
  "y0":2,
  "d1":{
    "x1":3,
    "y1":4,
    "d2":{
      "x2":5,
      "y2":6
    } 
  }
}
        

И для хранения его бинарного образа достаточно скажем <=N байт буфера, то какое бы значение не принимали члены этого блока данных, сколько бы незначащих нулей не было в числах, сколько бы пробелов и переводов строк не было внутри текстового JSON; в любом случае - N байт буфера всегда будет достаточно.

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

[jcxz 235]

1 час назад, Forger сказал:

Есть решение - создавать буфер динамически под размер всего файла json.

Динамическое выделение не увеличивает размер доступной ОЗУ в МК. Скорее наоборот - уменьшает. Не даёт никакого выигрыша.