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


Фотография

barr - битовые поля и бинарные массивы

bitfield binary array save memory barr

  • Авторизуйтесь для ответа в теме
Сообщений в теме: 3

Опрос: barr - битовые поля и бинарные массивы

Это открытое голосование. Другие пользователи смогут увидеть ваш выбор.

Какой новый функционал необходим?

Вы не можете видеть результаты проса пока не проголосуете.
Голосовать Гости не могут голосовать

#1 Оффлайн   Jakowlew

Jakowlew
  • Пользователи
  • Сообщений: 23
  • Уровень сигнала: 0,03%
  • В игре: 0 час. 17 мин.

Отправлено 11 Март 2018 - 13:16

Эта библиотека может быть полезна, если вы работаете с большим количеством числовых данных.

Основная цель - сэкономить память при хранении данных в небольшом диапазоне. Как известно, в Lua целое число занимает 64 бита и может принимать значения от -2^32 до 2^32-1. Такой огромный диапазон практически никогда не нужен и память расходуется впустую. Что если мы попробуем упаковать несколько маленьких чисел в одно большое?

 

Скачать библиотеку можно здесь: https://pastebin.com/WLmJ19QJ

Возможны изменения и доработка, так что проверяйте время от времени пастебин на наличие новой версии

Текущая версия: 1.1
1.0:
Первая версия, добавлены все основные методы

1.1: Добавлены методы barr:writeArray(array:table) и barr:readArray(pos:number, n:number):number
 

Пример:

Спойлер

 

Пример 2:

Спойлер

 

Если вы еще не устали, то вот подробная документация для задротов:

Спойлер
Когда использовать barr? Каждый пустой экземпляр barr занимает как минимум 48 байт и 544 как максимум (если порция состоит из 64 1-битовых полей, в таком случае лучше использовать порцию из 1 1-битового поля, тогда размер barr будет 48 байт).

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

 

Если это кому-то понадобится, то библиотека будет развиваться и обновляться. Все изменения буду дописывать сюда. Актуальная версия библиотеки тоже будет отображаться

 

Тесты:

Тесты проводились на чистом Lua 5.3

Код самого теста:

Спойлер
Результаты тестов:

Спойлер


Сообщение отредактировал Jakowlew: 14 Март 2018 - 21:52

  • Totoro и eu_tomat это нравится

#2 Онлайн   eu_tomat

eu_tomat
  • Хранители Кода
  • Сообщений: 911
  • Уровень сигнала: 6,14%
  • В игре: 49 час. 56 мин.

Награды

                          

Отправлено 11 Март 2018 - 15:37

Ой! А зачем же так код упакован? И Lua beautifier не хочет приводить его в порядок.
В общем, код я посмотреть пока не смог, а запускать не буду.

В связи с этим возникает вопрос: не приводит ли интенсивное использование этой библиотеки к обратному эффекту, о котором рассказывал ECS, когда сборщик мусора не успевает чистить интенсивно создаваемые и уничтожаемые объекты, от чего фактическое потребление памяти начинает расти?

#3 Оффлайн   ECS

ECS
  • Гуру
  • Сообщений: 204
  • Уровень сигнала: 0,51%
  • В игре: 4 час. 10 мин.
  • ГородСанкт-Петербург

Награды

   10                  

Отправлено 11 Март 2018 - 17:25

@eu_tomat, плюсую, хотелось бы глянуть и потестировать исходник без минификации. Еще интересует возможность практического применении подобной методики: безусловно, упор на экономию памяти - дело благородное, однако, к примеру, для отрисовки изображений и буферизации экрана идея не сгодится ввиду необходимости постоянной распаковки/упаковки чисел, что катастрофически снизит производительность. Это не претензия к либе, а вопрос о ее применении "не на бумажке"



#4 Оффлайн   Jakowlew

Jakowlew
  • Автор темы
  • Пользователи
  • Сообщений: 23
  • Уровень сигнала: 0,03%
  • В игре: 0 час. 17 мин.

Отправлено 11 Март 2018 - 18:25

@eu_tomat@ECS
Упаковал минифайером, чтобы скрипт меньше места занимал. Залил полную версию.

 

Судя по тестам, при кол-ве элементов около 1000 все происходит буквально мнгновенно, при кол-ве около 10000 - за сотые доли секунды. Тестил все не в опенкомпах, а на своем стареньком ноутбуке, Pentium dual-core, 1.3Ггц на ядро. Но в целом, упаковка/распаковка происходят в ~20-25 раз медленнее, чем при работе с обычными таблицами, причем время вроде как должно линейно расти при увеличении элементов чанка. Но, думаю, даже опенкомпы разницы при размере в 1000-2000 не заметят.

 

Касаемо памяти, тут все не однозначно. В пиковом потреблении памяти тратится больше примерно в 2-3 раза при небольшой длине массива. При n = 100000 память даже в пике тратится в 2.2 раза меньше, при n = 23000-24000 затраты одинаковы. В нормальном состоянии при записи 8-битных данных выигрыш начинается уже при n = 20-25

 

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


Сообщение отредактировал Jakowlew: 11 Март 2018 - 18:37





Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных