Перейти к содержимому
  • 0
ZiJer

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

Вопрос

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

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

Изменено пользователем ZiJer

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


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

Рекомендуемые сообщения

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

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

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

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


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

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

 

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

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

 

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")

 

 

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


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

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

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

 

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

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

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

 

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

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

 

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

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


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

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

 

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

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

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

 

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

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

 

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

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

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


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

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

 

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

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

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

 

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

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

 

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

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

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

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

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

Изменено пользователем ZiJer

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


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

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

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

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

 

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

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


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

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

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


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

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

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

Гость
Ответить на вопрос...

×   Вы вставили отформатированное содержимое.   Удалить форматирование

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

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

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

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


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