Уважаемые коллеги!

Подскажите, пожалуйста, по дилеме:

Есть такая вот структура:



К примеру мы добавили 10 row'ов (сделали rowList.add(booleanMassiv) 10 раз, т.е. добавили 10 булеан массивов)

Эта структура работает крайне быстро, поэтому хотелось бы либо оставить всё как есть (+ что-то докрутить), либо сделать аналог, который по скорости не уступает текущему.

Что я имею в виду говоря о скорости:

К примеру:


Как видите я просто исчу/считаю для каждого row'a соответствующую комбинацию. Т.е. к примеру размер булеан массива = 1000. Я смотрю, если какие-то указанные мной boolean индексы = true, то ответственный за такую комбинацию counter увеличиваем.

Есть только одна проблема, масштаб которой мне не понятен на данный момент. Так вот проблема - считается то всё быстро, но индексы у нас безымянные как для каждого row'a, так и для каждого булеан массива. А нужно, чтобы было что-то наподобии: row -> "nazvanie_rowa_1" : и индекс должен быть интегер, но не просто от 0 до N, а со своим уникальным номером (к примеру => 125233=true, 754345=false, а не 0=true, 1=false и т.д. для "nazvanie_rowa_1". На крайний случай можно использовать вместо "nazvanie_rowa_1" так же integer, но не просто дефаултный от 0 до N, а те, которые я сам захочу).

Есть ли какие-нибудь не менее скоростные решения, где можно кастомизировать row name + column name, т.е. по идее чтобы можно обратиться было так:

или на крайний случай


В общем текущее решение очень быстрое, но так же и бесполезное, т.к. если надо будет что-то поменять, мы не сможем сказать - где именно (или нам придется где-то на стороне делать bind, а это ужас в плане maintanance'a). Таким образом нужны какие-то ключи, по которым можно вычислить "адрес ячейки".

Сразу скажу, что я пробовал заюзать HashMap (как для row'ов так и для columnov, т.е. тогда я могу обращаться к "nazvanie_rowa_1" -> 652356), но скорость по сравнению с чистым битмапом разочаровывает. Для сраванения  отрабатывает за 15ms, в то время как HashMap + HashMap ~ за 350ms. Разница существенная.

Это сообщение отредактировал(а) linuxoid - 4.11.2012, 16:47

Вообще говоря для этого существуют константы (final или final static). Обращаемся по имени, используется значение. Причем "подстановка" происходит, если я правильно понимаю, фактически на стадии компиляции.

Всё-таки есть нюанс, из за которого не могу так сделать. 1 юзер (условно - админ) всё же должен иметь возможность манипулировать этим массивом: add, remove и т.д., т.е. делать полноценный CRUD.
Даже если бы небыло такой нужды, maintanance превратится в кошмар, т.к. очень много филдов, которые рано или поздно могут исчезнуть, добавиться и т.д. 

На данный момент вижу одно из решений:
Создать заранее массив по ширине и высоте намного больше, чем реально надо. Тогда можем инсертить в свободные ряды/колонки. А названия можно повесить, скажем, в 2 разных ArrayList'a. Единственное, боюсь, что в таком исполнении скорость работы резко возрастет и приблизится к HashMap + HashMap (если не больше).

Еще 1 вариант: максимально оптимизировать решение HashMap + HashMap. Мне уже удалось сбросить время на 100ms, но бывают и "неудобные" запросы, которые опять же могут увеличить скорость обработки..

Это сообщение отредактировал(а) linuxoid - 5.11.2012, 20:22

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

Пардон, я ошибся и имел в виду что увеличится время обработки, а не скорость.

Видимо это твоя эмоциональная сторона разместила пост, которая решила продемонстрировать свои выдающиеся саркастические возможности. Я тебя понимаю.
Потому что если бы ты немножко подумал, то понял бы, что речь не идет об оптимизации самой структуры HashMap'a, а лишь об оптимизации кода, который обращается к этой структуре. К примеру, если отказаться от создания отдельных методов и выполнять весь цикл в 1 методе, то мы не тратим дополнительное время (существенное при больших объемах), связанное с реализацией ООП; так же имеет значение последовательность выполняемых операций. Выгоднее делать сначала AND (всегда 1 проверка), но OR уже после (т.к. вариантов перебора может быть >= 1) и т.д. В результате получаем оптимизацию. И никакого чуда, о котором ты говоришь нету, одни хлопоты..

Так что ВЫДОХНИ, дружище ;)

P.S. И не обижайся, пожалуйста, если по делу что-то отпишешь, я только рад.

Это сообщение отредактировал(а) linuxoid - 7.11.2012, 00:36