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

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

Вопрос

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

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

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

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


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

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

  • 0

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

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

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

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


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

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

 

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

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

 

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

 

 

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


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

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

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

 

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

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

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

 

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

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

 

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

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


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

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

 

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

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

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

 

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

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

 

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

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

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


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

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

 

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

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

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

 

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

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

 

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

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

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

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

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

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

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


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

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

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

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

 

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

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


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

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

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


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

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

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

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

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

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

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

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

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


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