Сначала для скептиков суть:
Есть конструкция состоящая из множества элементов, которые состоят ещё из множества элементов и те ещё раз из множества элементов. И всё это рассматривается в наборе точек по времени, да ещё и для разных исходных данных. Потому возможна ситуация массива аж 5 уровня вложенности (да даже больше возможно).

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

Структура данных представляет из себя что-то типа:




Ну и так далее, как видите присутствуют ещё куча (тут далеко не все) параметры конкретного расчета/времени/сечения/..

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

Пока у меня из мыслей только двухкратное считывание файлов:
первый раз для формирования размеров массивов, формируем размеры массивов,
второй раз уже заполняем.
Но тоже как-то костыльно...

wadmanВсе задачи не видно, только один отдельно взятый костыль.

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

Цели у задачи тоже нет. Я-бы в её качестве использовал любую БД. В этом случае размерность не особо нужна при передаче данных.
Вся задача на данный момент - визуализация, обработка, сохранение результатов расчётов. Результаты получаются посредством другой расчётной программы, лезть в которую пока очень не хочется (хотя если припрет - придется, но в чужом коде разбираться ...). Про xml не в курсе.
С БД уже обжегся, когда надо быстро работать с миллионами значений скорость работы с обычными бесплатными БД (что очевидно) стоит на несколько(много, крайне много) порядков ниже работы с оперативной памятью.

LocksmithPCАндрей Игоревич, с какой БД работали?
Спросите что-нибудь попроще :), тем более у большинства названия "что-то-там-SQL-что-то-там".
Вроде Firebird и MySQL, но уже не помню.
А что существуют БД способные быть ну хотя бы не более чем в 100 раз медленнее, чем прямое обращение к ячейке оперативной памяти?
Думаю там вообще разница по скорости обращения и считывания в десятки тысяч раз, ну чисто технически. (если не брать монструозных серверов c огромными RAIDмассивами ССД дисков).

alekcvpНет, вы получите фрагментацию памяти и она закончится для вашего приложения раньше, чем реально закончится.

Андрей Игоревич2. Существуют ли способы сразу указать для всех массивов нижнего уровня их размер не перебирая.

Андрей Игоревич3. Существуют ли более удобные способы работы с таким форматом данных?

Пока у меня из мыслей только двухкратное считывание файлов:
первый раз для формирования размеров массивов, формируем размеры массивов, второй раз уже заполняем.
Но тоже как-то костыльно...
ИМХО - самый нормальный подход. Второй вариант: заранее выделить буфер минимально-необходимого размера, которого гарантированно хватит для любых данных, после считывания из файла - выделять ещё один буфер по фактическому размеру данных, копировать их в него, а в исходный считывать новый файл. Что будет быстрее: ваш вариант или мой - зависит от разных условий.
Ясно, спасибо, так, наверное, и поступлю.

LocksmithPCАндрей Игоревич, а про индексы помните?
Нет. А о чем речь?
Я когда тестировал - просто попробовал записать миллиард значений в БД, за несколько часов даже процента не записало (это с ССД).
При считывании в оперативную память хватает (с того же ССД в 64 битное приложение) - хватало несколько минут.

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

Не понял о чем речь. Что такое "бизнеслогика"? БД быстрее складывают/умножают/возводят в степень/присваивают?
Мигалкаавтор! бд будет отдавать вам данные из озу причем только те которые будут нужны вам сейчас. вам же не надо каждый миг обрабатывать все ваши десятки гигов, вам нужен какой-то срез или агрегат, а это как раз то что БД делает лучше всего. если, конечно, вы будете использовать БД как БД, а не тупое хранилище.
Десятки гигов - нет, сотни мегабайт - вполне может быть, хотя я и стараюсь такого избегать (вычислив или подготовив нужное заранее).

Мигалкахарактерные скорости озу сейчас - десятки гигабайт в секунду. ваш код после загрузки всех данных в озу какую покажет скорость обработки всех ваших данных, предположим 100ГБ? предскажу что это близко не будут теоретически возможные 10 сек. ещё раз обращу внимание - "обработка всех данных", т.е. как минимум один раз прочитать весь объём и что там обсчитать.

Конкретно сейчас вопрос о 100гб не стоит (но стоял ранее), но прямое обращение к ССД в принципе переберет эти 100Гб за минуты, что бы добиться такого от БД надо быть явно не любителем, как я.

LocksmithPCМигалка, BDE залил лям записей в таблицу paradox примерно за минуту.
поля: autoinc & numeric(18, 2). numeric индексирован
Если вернуться к давнему вопросу о миллиардах (НЕ миллионах) значений, умнож минуту на несколько тысяч - сколько там в часах выйдет?
vavanАндрей Игоревичпопробовал записать миллиард значений в БД, за несколько часов даже процента не записалонекоторые бд/движки умеют балками оперировать, порой вполне может и тысячами (а то и десятками их) в секунду писатьВасилий 21) SQLite из коробки умеет делать in-memory DB
2) XML тут ну вот никак не поможет, т.к. будет сделан скорее всего на тех же самых массивах и сожрет памяти еще и побольше, чем у ТС.
3) Для дин.массива структур с полями-дин.массивами особого жора памяти при расширении не будет, т.к. размер самого массива (т.е. Sizeof(elem)*Length(array)) невелик. Именно Sizeof(elem) определяет размер элемента, а не сумма размеров всех данных, на которые он ссылается. ТС, ты прикинь, может, и нет нужды что-то выдумывать
Да понимаю я, что и БД можно достичь скорости сопоставимой со скоростью прямого чтения/доступа к диску. Но давайте будем честны, для огромных баз это потребует не базового умения работать с БД и кучу дополнительных условий. Что мне ну совсем не хочется делать. Я не программист, я пишу код для своих расчетных нужд, а подобный уровень изучения БД был бы логичен, если бы это была моя профессия.

YuRockLocksmithPCАндрей Игоревич, вам надо обработать за раз весь миллиард?Это самый интересный вопрос. На который так я и не увидел ответа.
А то если нет - то в СУБД как минимум поиск необходимого диапазона из этого миллиарда произошел бы в порядки раз быстрее, чем в цикле по массиву.
Про миллиард сейчас не скажу, но миллион, вроде как перебирается/присваивается менее чем за секунду при работе в оперативной памяти напрямую.
Ну и опять же, на данный момент у меня полностью самодостаточное приложение, скопировал вместе с нужными файлами на любой компьютер под виндой, и работай сколько хочешь, ни прав никаких не надо, ни сервера никакие поднимать.
С БД это уже далеко не так просто (хотя вроде как есть решения, но не самые удобные).

softwarerАндрей ИгоревичСначала для скептиков суть:
Да какие скептики и какая суть... и так видно, что основная проблема задачи - в уровне исполнителя.
Спасибо, но к чему?

softwarerАндрей Игоревич1. Корректно ли увеличивать массив (например самого нижнего уровня) при каждом добавлении на 1 элемент, особенно когда общий размер массива становится несколько сотен мегабайт?
Это относительно корректно, но крайне неоптимально. Примерно как сортировка пузырьком - так можно делать только тогда, когда есть железобетонная уверенность в избытке ресурсов по сравнению с задачей.
Андрей ИгоревичЕсли нет, то как это можно обойти, если до самого момента считывания я не могу не знать о размерах массива?
Зависит от того, как именно организовано хранение файлов, логика считывания и т. п., вариантов много. Наиболее стандартный универсальный способ - выделять с запасом, а потом корректировать. То есть, первоначально выделить десять элементов, когда считан одиннадцатый - увеличить размер до сотни, когда считан сто первый - до тысячи и т. п. После считывания последнего элемента установить точный размер.
Интересное решение, надо попробовать.

softwarerАндрей Игоревич2. Существуют ли способы сразу указать для всех массивов нижнего уровня их размер не перебирая.
Вопрос крайне сомнителен и непонятен, но в целом короткий ответ - нет.
А что тут непонятного. Есть, допустим, Х-массивов 3го уровня, каждый имеет A*Y - массивов 4го уровня, те, в свою очередь по B*Z массивов 5го. Можно ли сразу всем массивам задать нужный размер не пробегая по каждому? Например, часто бывает что двигаешься по файлам конструкции одного типа и уже заранее знаешь все размеры массива. В принципе предложенный выше вариант с присвоением приемлем.
Ну и совместно с предыдущим пунктом - есть ли способ задать размер массива "по умолчанию"? Ну выделил я массив высокого уровня и там сразу все массивы нижнего уровня сразу имеют начальные размеры, или всё-таки надо руками размеры прописать?

softwarerАндрей Игоревич3. Существуют ли более удобные способы работы с таким форматом данных?
Способы зависят от данных и от логики работы с ними. Единственно возможный короткий ответ - нужно, чтобы эту задачу посмотрел программист. А там может оказаться так, что данные лучше всего вообще потоково обрабатывать при считывании и нигде не хранить.
Потоково работать можно только с ССД, иначе при каждом действии возникают сильные лаги. На данный момент в программе вся информация доступна мгновенно, и присутствует минимальная анимация, при работе с жестким диском (той же БД) это будет куда менее удобно.

Vlad FВам подсказать достаточно простые способы скоростной вставки в БД на основе FB embedded, который, к слову, можно расположить внутри каталога приложения и копировать вместе с ним, точно так же ничего не настраивая?
Спасибо, пока не надо. Для данной задачи БД избыточна. Когда возникнет необходимость работать с объемами выходящими за рамки оперативной памяти - попробую ещё раз воспользоваться БД.

LocksmithPCАндрей Игоревичпропущено...

Если вернуться к давнему вопросу о миллиардах (НЕ миллионах) значений, умнож минуту на несколько тысяч - сколько там в часах выйдет?


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

3ккк значений (вполне обычный массив данных объемного распределения значений, максимум который был у меня 60ГБ) - 50 часов.
Но к вопросу данной темы это никак не относится, это уже дела минувших или грядущих дней.
Сейчас размеры массивов исчисляются сотнями мегабайт и спокойно уживаются в оперативной памяти, при том предоставляя мгновенный доступ.

LocksmithPCА вариант с внешними таблицами фаера уже был?
Развернуть данные в:

Так по сути с внешних таблиц это и грузится... Можно работать и напрямую с ними, просто медленно и неудобно.