Сохранение и чтение массива

[ZiJer 6]

Мне нужен самый ресурсосберегающий (в плане процессорного времени и объема энергонезависимой памяти) способ

сохранения одномерного целочисленного массива в файл и его последующее чтение для воссоздания исходного массива.

Изменено 18 января, 2017 пользователем ZiJer

[NEO 542]

Мне нужен самый ресурсосберегающий (в плане процессорного времени и объема энергонезависимой памяти) способ

сохранения одномерного целочисленного массива в файл и его последующее чтение для воссоздания исходного массива.

Бинарный режим. 4 байта на ячейку.

[SDV 784]

способ сохранения одномерного целочисленного массива в файл и его последующее чтение для воссоздания исходного массива

 

Честно, даже не понял что и для чего это нужно.

У меня только в голове крутится тупо обычное чтение и БИНАРНАЯ запись в файл.

 

local function readfile(path)
file = io.open(path, "r")
print(file:read("*a"))
file:close()
end

local function savefile(path, value)
file = io.open(path, "a") -- или режим w если с перезаписью
io.output(file)
io.write(value)
file:close()
end

savefile("test.txt","1")
readfile("test.txt")

 

 

[eu_tomat 2 155]

Бинарный режим. 4 байта на ячейку.

Во-первых, Lua позволяет оперировать целыми числами заметно длиннее четырех байт. Если я верно помню, можно свободно рассчитывать на 53 бита.

 

Во-вторых, автор вопроса не уточняет свойства хранимых в массиве чисел:

А если числа в массиве сильно ограничены, помещаясь в один байт?

А если числа в массиве часто повторяются?

 

Тогда дисковая память будет расходоваться неэффективно.

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

 

Поэтому придется ответить на еще один вопрос: какое соотношение между занимаемым объемом и выполненными вычислениями является оптимальным?

[NEO 542]

Во-первых, Lua позволяет оперировать целыми числами заметно длиннее четырех байт. Если я верно помню, можно свободно рассчитывать на 53 бита.

 

Во-вторых, автор вопроса не уточняет свойства хранимых в массиве чисел:

А если числа в массиве сильно ограничены, помещаясь в один байт?

А если числа в массиве часто повторяются?

 

Тогда дисковая память будет расходоваться неэффективно.

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

 

Поэтому придется ответить на еще один вопрос: какое соотношение между занимаемым объемом и выполненными вычислениями является оптимальным?

4 байта хватит с головой.

[ZiJer Автор вопроса 6]

Во-первых, Lua позволяет оперировать целыми числами заметно длиннее четырех байт. Если я верно помню, можно свободно рассчитывать на 53 бита.

 

Во-вторых, автор вопроса не уточняет свойства хранимых в массиве чисел:

А если числа в массиве сильно ограничены, помещаясь в один байт?

А если числа в массиве часто повторяются?

 

Тогда дисковая память будет расходоваться неэффективно.

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

 

Поэтому придется ответить на еще один вопрос: какое соотношение между занимаемым объемом и выполненными вычислениями является оптимальным?

Числа от нуля до 0xFFFFFFFFFFFF включительно.

Числа повторяются но через определенные интервалы, в большинстве случаев, достаточно часто.

Думаю, скорость все же в приоритете.

Спасибо за наводку, мне пришла одна мысль (возможно выложу решение, если смогу написать).

Изменено 18 января, 2017 пользователем ZiJer

[eu_tomat 2 155]

Числа от нуля до 0xFFFFFFFFFFFF включительно. Числа повторяются но через определенные интервалы, в большинстве случаев, достаточно часто.

48 бит – это довольно много.

Можно поинтересоваться, для чего в Майне потребовались такие большие целые числа?

 

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

[ALeXeR 67]

Эм, ты уточни, это в реале или в игре? Так как в игре ремурмоемкость операций в основной массе зависит не от сложности и обьема операции а от количества операций в целом, со стороны игры самыми производительными операциями являются нативные и задержка основывается на количестве вызовов, так что нужно спавлятся нативными методами, например по скорости было бы быстрее засыпать файл в ОЗУ одним чтением, но вопрос - хватит ли ОЗУ? Закон о зажираемой памяти и быстро действии никто не отменял)