Предложите структуру данных
Сижу и думаю над проблемкой.
Дана форма. Произвольная, аспх... но не повредит и ВинФорм...
На форме лежат блоки полей... Блоки - т.е. несколько блоков по несколько полей.
Доступ к полям - по именам. Можно проверить (сделано через ТО место, но работает хотя и медленно) видимость отдельного поля.
Требуется - если ВСЕ поля в блоке невидимы - утилизировать клиентском экране пространство занимаемое данным блоком.
Требуется - сделать подсистемку быстрой проверки на необходимость утилизировать блок.
Пока слепил два словарика (данные по тестовому проекту, "ЦоллапсаблеРощ_" - коллапсируемый блок):
[пре]
статиц Дицтионары<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.
------
Учитывая, что потенциальным источником может быть не МССЯЛОракле/МыСЯЛ & етц, а какой-нибудь веб-сервисе с отдачей представляемого ХМЛа, я бы не закладывался на количество...
Пока оставил структуру как есть - один прямой словарик, другой - обратный... Что-нибудь с подсчетом делать не стал - слишком много связанных изменений в других частях...

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

Не понял, разве это не форма ввода/вывода данных?

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

Ткни пальцем - какой из ТЕХ классов решает мою проблему?

ты сначала проблему опиши так, чтобы она была понятна ;-)

Ну давай на пальцах...
Дана Веб-страница или Вин-форма...
На странце/форме в виде блоков размещены управлляющие элементы - лэйблочки, инпуты, картинки и т.п.
Когда все елементы в блоке невидимы - необходимо очистить (сделать доступным для размещения других
элемнтов) занимаемое ими место.
Вопрос - Какая структура данных позволит принять решение об освобождении блока за минимальное
количество операций?
Для вкусности - решение должно быть применимо как на серверной части, так и на клиенте...

речь о структуре, которая содержит значения (block, controls), или о структуре, которая содержит значения (controlID, visibility)?

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

Тогда имеет смысл ввести еще структуру (blockID, visibility). Но не это главное.
Насколько я понял, у тебя основное действие над структурой - это считывание значений, а не их изменение. Тогда структура выбрана правильно. Самое быстрое считывание у Dictionary<TKey, TValue>

Тогда имеет смысл ввести еще структуру (блоцкИД, висибилиты).
------
А как это должно работать??? в вебе?

С чего это должно меня интересовать?
Форма на экране просто не может иметь "бесконечное" число данных, хотя если ты их собираешься скроллировать на клиенте....

У нас требования сильно разные. Для чего вам может требоваться встроенный контрол, думаю никто не додумается в здравом уме
А вообще я в подобных случаях пользую виртуальный грид или проперти грид (только не MS!) Вся динамика определяется состоянием данных автоматом.

а в чем проблема?
где вы вообще храните информацию о visibility?

Форма на экране просто не может иметь "бесконечное" число данных
-----
Зато ничто не мешает ей их динамически подгружать... Понимаю - каша... жуткая каша даже для прямой имплементации, а уж в генерации... Ну и что - приходится есть...
никто не додумается в здравом уме
-----
Ну не встроенный, а встраиваемый... включая динамическое встраивание...
Но ты прав - никто, в здравом уме, не будет такой фигней маятся... но Я, по земным меркам, уже давно не в здравом - даже в паспорте написали - с ДРУГОЙ планеты...

ну сами данные подгружать еще да, но не layout ведь.
А делать динамический layout это ведь брр, да и ты об этом ничего не писал.

не уверен поможет ли тебе это, так как не знаю вообще что ты там пилишь: в ассоциативном массиве. возьми и засунь к примеру в JSON, не ошибешься. тебе и на клиентской части и на серверной будет просто обращаться к этим данным.

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

это ведь брр....
-----
Ну это по первому разу... А когда его делать обучен автомат - уже не брр, а кайф...
но не лаёут ведь.
------
Ты код, генерируемый Телериком, смотрел?

в ассоциативном массиве.
-----
Так вопрос именно в том - что именно туда надо засунуть? - перекинуть туда-сюда у меня проблемы никогда не было... а вот нужно ли перекидывать и можно ли этого избежать - тут думать надо...

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

Хочешь сказать что layout формы меняется в зависимости от введенных данных? И шеф считает это крутым решением?

Считаешь что я пользую что то от Телерика или хоть какой то генерируемый код?
Хотя пожалуй вру. Микрософт Pex пробовал. Если делать все в нем и код не смотреть никогда - пойдет.
Но у нас была идея пользовать его начальный генератор для последующей дорабки вручную.

Я спросил не тип данных, а какую структуру данных выбрать.
И не зависит оно ни от чего, кроме фактической иерархии элементов, что для Веба есть ХТМЛ...

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

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

Похоже угадать не получится.
Прийдется пытать. Деда Мюллер Ау!
Когда layout становится известен? Когда он может изменится и как часто это может происходить?
Все ли элементы видны сразу на экране (имеется в виду скроллирование)? Сколько различных типов элементов возможно?

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

ошибся конечно грубо, но я имел ввиду таки структуру данных. ;)
очень смутно понятно что ты там пилишь. генератор приложений на все случаи жызни. :D ... смутно как то все.

имеешь в виду после того как станут известны все данные принадлежащие форме? Скажем после чтения базы. А если форма изначально пустая?

Ну мы ведь не на представлении Копперфильда. Должна быть какая то причина изменения лайаута страницы.

Скроллинг или есть или его нет. Элементы с данными или видимы на странице или они нафиг не нужны, так как будут автоматом невидимы.

Ну что там у тебя есть поля ввода, label, списки, грид?