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

1. ViewState["Calendar1.SelectionMode"] = Calendar1.SelectionMode;
2. ViewState["CSM"] = Calendar1.SelectionMode;
3. ViewState["Calendar1_SelectionMode"] = Calendar1.SelectionMode;

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

4
ojblass 1 Апр 2009 в 07:32

3 ответа

Лучший ответ

Вариант два, вероятно, даст вам лучшую производительность, но разница крайне мала. Если вы испытываете проблемы с производительностью, это будет одно из последних мест, где я буду искать узкие места. Вы запускали какое-либо профилирование на своей странице? Вот где я бы начал искать.

7
pbz 1 Апр 2009 в 07:40
Он работает медленнее, чем мне хотелось бы, но ничего официального. Это странно, но я думаю, что на самом деле могу заметить разницу, когда только тысяча строк набита там более длинными именами. А вот мой домашний компьютер - куча. Какой инструмент профилирования вы бы порекомендовали?
 – 
ojblass
1 Апр 2009 в 07:43
Вы можете попробовать включить трассировку страницы (quickstarts.asp.net/quickstartv20 / aspnet / doc / monitoring /…) и посмотрите, даст ли это какие-нибудь подсказки. Что касается реальных профилировщиков, то есть профилировщик CLR или некоторые коммерческие, такие как Ants или DotTrace.
 – 
pbz
1 Апр 2009 в 08:04
Спасибо за ссылку на информацию о профиле. Мне нужно применить более строгий подход к моему анализу, но я пришел к выводу, что это действительно влияет на характеристики нагрузки.
 – 
ojblass
2 Апр 2009 в 04:07

Имена клавиш становятся частью скрытого поля viewstate. Грубый пример:

protected void Page_Load(object sender, EventArgs e)
{
    // ViewState["a"] = 1;
    // <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE"   
    // value="/wEPDwUJNzgzNDMwNTMzDxYCHgFhAgFkZCdtAzza2+uuoGpYdGLBUdCkUGe7" />

    // ViewState["this is a very very very very long key"] = 1;
    // <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" 
    // value="/wEPDwUJNzgzNDMwNTMzDxYCHiZ0aGlzIGlzIGEgdmVyeSB2ZXJ5IHZlcnkgdmVyeSBsb25nIGtleQIBZGSmj9cou408+XXRLxCLKcEoLngriA==" />

}

Итог: если вы не храните большое количество ключей, скорее всего, это не проблема.

4
andleer 1 Апр 2009 в 07:45
Но это действительно увеличивает трафик, да?
 – 
ojblass
1 Апр 2009 в 08:26
Да, это увеличивает размер вашей страницы. Ваш трафик увеличится.
 – 
andleer
1 Апр 2009 в 14:51
Большой - немного произвольное слово. 120 и 270 считаются большими?
 – 
ojblass
2 Апр 2009 в 04:10
Я бы сказал, что всякий раз, когда размер вашего состояния просмотра> 1k, вы, вероятно, злоупотребляете им. Некоторые поставили бы эту планку еще ниже. Если у вас большой объем сайта, это может быть проблемой.
 – 
andleer
2 Апр 2009 в 19:30

Используя показатели производительности, ответ на самом деле - да, имена ключей, которые вы вводите в ViewState, действительно влияют на характеристики загрузки. Воздействие не является серьезным и, похоже, не нарастает линейно.

Критическая точка оказалась на уровне 120 объектов. Следующая статистическая разница появилась примерно на 270 объектах. Обратите внимание, я изменял только размер клавиш и продолжал вставлять объекты Calendar.SelectionMode. Я выбираю ответ, который помог мне прийти к выводу, приведенному выше.

Окончательный контрольный показатель:

Эффект: ВРЕМЯ ЗАГРУЗКИ С ИСПОЛЬЗОВАНИЕМ БОЛЬШИХ КЛЮЧЕЙ - ВРЕМЯ ЗАГРУЗКИ С ИСПОЛЬЗОВАНИЕМ МАЛЕНЬКИХ КЛЮЧЕЙ.

  • 0000 - 0120 0,007 секунды
  • 0120 - 0270 2,254 секунды
  • 0270-1050 2,956 секунды
  • 1050–2000 4,873 секунды

Точность результатов составляет 0,05 секунды с доверительным интервалом 99%.

1
ojblass 6 Апр 2009 в 07:05