Предложите структуру данных
Сижу и думаю над проблемкой.
Дана форма. Произвольная, аспх... но не повредит и ВинФорм...
На форме лежат блоки полей... Блоки - т.е. несколько блоков по несколько полей.
Доступ к полям - по именам. Можно проверить (сделано через ТО место, но работает хотя и медленно) видимость отдельного поля.
Требуется - если ВСЕ поля в блоке невидимы - утилизировать клиентском экране пространство занимаемое данным блоком.
Требуется - сделать подсистемку быстрой проверки на необходимость утилизировать блок.
Пока слепил два словарика (данные по тестовому проекту, "ЦоллапсаблеРощ_" - коллапсируемый блок):
[пре]
статиц Дицтионары<string, string[]> рощБлоцкс = нещ Дицтионары<string, string[]> {
{ "ЦоллапсаблеРощ_ФеедНаме",
нещ стринг[] { "ФеедНаме", "ПресцриптионМеасурементИД", "ПресцриптионЯуантиты" } }
};
статиц Дицтионары<string, string> паренталДепенденцы = нещ Дицтионары<string, string> {
{ "ФеедНаме", "ЦоллапсаблеРощ_ФеедНаме" },
{ "ПресцриптионМеасурементИД", "ЦоллапсаблеРощ_ФеедНаме" },
{ "ПресцриптионЯуантиты", "ЦоллапсаблеРощ_ФеедНаме" }
};
[/пре]
и метод, вызываемый после изменения каждого поля.
Это работает, но довольно медленно.
Вот сижу и думаю - Как ускорить?
Понятно, что надо что-то кешировать...

Сколько у вас запросов в секунду, что это тормозит? Пробовали профилять, что именно тормозит - процедура вычисления видимости одного поля, вычисление видимости блока или сборка мусора? Если первое - то очевидное решение сделать еще кэш на видимость одного поля, но тут нужна от вас дополнительная инфа, от чего зависит ваша видимость, кроме имени поля (от имени пользователя, даты, еще чего-либо), чтобы посоветовать, стоит ли оно того. Еще одно очевидное решение - перейти от доступа по именам полей к доступу по целочисленному порядковому номеру или по объекту (объекты должны быть глобальными и с референс эквалити), вычисление кэша и сравнение в этом случае будет сильно быстрее, и памяти будет тратиться меньше.
P.S. статиц Дицтионары ЦоллапсаблеРощ_ - это зачет :)

Сколько у вас запросов в секунду, что это тормозит?
------
Не знаю. Я вообще никогда и принципиально не знаю как будет использоваться система. Моя задача - построить ее построитель грамотно, не зная об ней ничего, кроме факта, что есть база данных с которой будет работать система.
или сборка мусора?
-----
Что такое сборка мусора применительно к статическим переменным?
от чего зависит ваша видимость, кроме имени поля
------
На этом уровне - только от имени поля. Проверка ролей и прочего - уже сделаны до этого.
перейти от доступа по именам полей
-----
Невозможно. В данном случае - по политическим и историческим мотивам...

Хорошо, переформулирую вопрос. Когда вы говорите, что "это работает, но довольно медленно", то на каком количестве запросов у вас это самое "медленно"? Потому что выглядит очень странно, что обработка нескольких десятков (ну пусть даже сотен) полей настолько тормозит. Подозреваю, что проблема с тормозлом не там, где вы ее ищете. Попробуйте попрофайлить, чтобы точно установить, что именно тормозит. Рекомендую dotTrace, там есть trial версия.

Вот на каком "этом" уровне? Вопрос о зависимости я задал с тем, чтобы понять, нужен ли кэш per request или глобальный, на уровне всего приложения. Если делать глобальный, то надо понимать, чем его индексировать. Если оно у вас ни от чего не зависит, то вы вообще можете посчитать видимость полей и блоков один раз на все приложение, закэшировать и вуаля - проблема решена.

Как ты умудрился код перевести? Такое даже в страшном сне не приснится.
Из приведенного кода может быть ясно что ты собрался ускорять Dictionary
Все остальное к бабе Ванге.

то на каком количестве запросов у вас это самое "медленно"?
-----
Объясняю еще раз - у меня нет количества запросов. У меня даже нет кода, в котором эта часть должна работать.
Медленно, в данном случае, означает, что код, проверяющий видимость полей вызывается для КАЖДОГО поля.
Внутри - все просто - прокручивается содержимое словаря и проверяется состояние полей. Для каждого поля.
Хотелось бы исключить ненужные проходы.
то надо понимать, чем его индексировать
-----
Есть два доступных на момент генерации элемента - имя поля и имя блока, если он может быть коллапсирован.
Известно также, какие именно поля вложены в блок.
Если оно у вас ни от чего не зависит
------
Оно просто динамическое - админ настраивает что видимо, а что нет... При полной статике - Я бы просто не генерерил код ненужных полей...
Попробуйте попрофайлить
-----
У меня не приложение, а генератор приложений - мне надо сейчас решать где будет "узко" в результирующем коде, независимо от того какой именно код будет.
Я так думал, что может быть есть смысл сделать простым подсчетом колличества невидимых полей?

Он на Глаголе программирует.

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

откуда у Мурки в его деревне манагед глагол?

Ты бы хоть вначале цикл нарисовал и хоть какую то цифровую ориентировку дал

Не слышали выражения premature optimization is the root of all evil? Вот вы именно этим evil-ом и занимаетесь, а именно растрачиваете драгоценное рабочее время не известно на что. Я тоже таким был. Но опыт мне доказал: тормозит не там, где изначально думалось, а совсем в другом месте. Поэтому правильный подход - это нагрузочное тестирование. Оно поможет вам выяснить, действительно ли есть тормоза, и, если есть, то профайлер поможет вам выяснить, где именно. Это все не значит, что надо писать код как попало. Конечно, старайтесь оптимизировать там, где это сделать просто. Если же вы не видите, где здесь можно оптимизировать, то лучше соптимизируйте деньги вашего работодателя - напишите код так, как вам придумалось, в 95% случаев он не будет тормозить.
В данном случае я попытался бы сделать статический кэш видимости блоков, пересчет бы запускал при первом обращении и при изменении видимости полей админом.

Murr считает, что настоящему программисту достаточно и первого, чересчур детального поста.

Ну это завтра... где-то после обеда...

Понимаю, на голодный желудок плохо пишется
Завтра приведешь кусок интерфейса и спросишь, отчего при вызове метода А возникает нуль поинтер эксепшион И как бы это оптимизировать что бы было деление на ноль.

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

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

перефразирую: у меня есть коллекция из 3х элементов, подскажите, какой алгоритм сортировки выбрать? Применил пока пузырьковую, но меня не устраивает сложность - O(n2). Склоняюсь к использованию неустойчивой сортировки.
имхо страдаешь фигнёй :)

Нестыковочка батенька. Нельзя сгенерировать то что неизвестно.
Ладно, можно не знать как будет называться Label и сколько их будет всего. Но явно что гораздо менее 1000.
Да и какой-то паттерн использования должен быть.
Короче, слабо верится, что нельзя построить пару наихудших случаев и пару стандартных случаев.
Ну а так Мурка писала код, можно предположить что затыков нигде не будет. Спи спокойно

Но явно что гораздо менее 1000.
------
Учитывая, что потенциальным источником может быть не МССЯЛОракле/МыСЯЛ & етц, а какой-нибудь веб-сервисе с отдачей представляемого ХМЛа, я бы не закладывался на количество...
Пока оставил структуру как есть - один прямой словарик, другой - обратный... Что-нибудь с подсчетом делать не стал - слишком много связанных изменений в других частях...

какой алгоритм сортировки выбрать?
-----
Вопрос был - Чем заменить коллекцию, что-бы избежать необходимости сортировки...