Требуется очень большая структура данных. Ищу идеи

Question

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

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

Вот основная часть проблемы.

• 500х500 сетка из шестиугольников. прим.
• Они меняются не очень часто, но могут меняться.
• Разбить его на разделы 50x50 или 100x100 очень выполнимо, однако возможно, что кто-то сможет бегать с одного конца карты на другой, поэтому мне нужно иметь возможность разобраться со всем этим в какой-то момент, даже если это в разделах.
• Это, очевидно, приведет к большой потере памяти.

Я могу хранить данные (общие переменные) как простой byteArray или даже в виде обычного текста. Информация в гексе очень проста, просто их много. Я не "должен" сохранять данные. (будет особенность)

Базовая структура на шестиугольник:

• шестнадцатеричный цвет (очевидно, с контуром) (или растровое изображение) блиттинг кто-нибудь!
• TextField с числом в нем. (максимум 2 цифры)

Это почти вся необходимая информация.

Если бы вообще не было возможности изменить гекс, это было бы довольно тривиально.

Так что мне любопытно, есть ли у кого-нибудь идеи по этому поводу. (любые абсолютные истины не были бы плохими;)

Редактировать: О, информация о гексах приходит через поток TCP. Это не проблема, как я сказал, что данные упрощены по гексам, и мой анализатор работает молниеносно, поэтому это не проблема.

Обновление: возможность создавать и поддерживать 250 000 объектов (гексов) - это то, что заставляет меня чаще всего задавать этот вопрос. Вот почему я ищу идеи. (250 тыс. Объектов во флэше - это хорошо)

Answer 1

Базовая структура для каждого шестиугольника:

* hex color (with outline obviously) (or a bitmap picture) blitting anyone!
* TextField with a number in it. (max 2 digits)

Я полагаю, вам не нужно хранить все 250K TextFields и растровые изображения, поскольку они должны существовать только на экране,Упакуйте эти данные в небольшое количество байтов - максимум 2 цифры составляют 7 бит, добавьте идентификаторы цвета из вашей палитры (или 24 бита, если вам нужен truecolor) и идентификаторы растрового изображения.Если вы создаете структуры одинакового размера, вы можете записать их в ByteArray.Это позволит вам избавиться от ссылок на объекты размером 250 КБ и предотвратить возможную фрагментацию памяти.
Тогда вам нужно всего лишь создать функции упаковки / распаковки для этих байтов в некоторые пригодные для использования объекты (не забывайте пулы объектов) и выполнять аритметику, чтобы получитьих от ByteArray справа.Как отмечали другие, 250K ячеек не много, если вы упаковываете данные ячейки в пару целых чисел.

Answer 2

Может быть, вы могли бы подойти к этому как упражнение в дедупликации данных?Например, не более 100 различных текстовых значений, которые могут быть связаны с вашими гексами.Предполагая, что вы действительно используете небольшое количество различных шестнадцатеричных цветов (например, менее 20), тогда относительно небольшой набор шестнадцатеричных экземпляров может представлять каждую возможную шестнадцатеричную конфигурацию.Таким образом, у вас может быть такая служебная функция (неверный синтаксис ActionScript, извините):

Hex getHex(int color, String label)

..., которая проверяет, существует ли уже гекс с данной конфигурацией, исоздает только новый экземпляр Hex, если он еще не существует.

Таким образом, у вас все еще есть 250 000 ссылок в вашем массиве (или любой другой структуре, которую вы используете для отслеживания ваших гексов), но только гораздо меньшее количество реальных экземпляров объекта.Похоже, что это должно быть управляемым, даже во Flash.

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