Разница в производительности в цикле

Question

Будет ли огромная разница в производительности между:

if (this.chkSelectAll.Checked)
    for (int i = 0; i < this.listBoxColumns.Items.Count; i++)
        this.listBoxColumns.SetSelected(i, true);
else
    for (int i = 0; i < this.listBoxColumns.Items.Count; i++)
        this.listBoxColumns.SetSelected(i, false);

против

for (int i = 0; i < this.listBoxColumns.Items.Count; i++)
    this.listBoxColumns.SetSelected(i, this.chkSelectAll.Checked);

Какой из них рекомендуется. Краткая кодировка в сравнении с увеличением производительности?

Answer 1

Я бы не ожидал увидеть большую разницу в производительности, и я бы, конечно, согласился с последним, поскольку он более читабелен. (Я бы поставил фигурные скобки вокруг него.)

Довольно легко представить ситуацию, когда вам может понадобиться изменить цикл, и в первом примере вы можете случайно изменить только один из них вместо обоих. Если вы действительно хотите избежать вызова свойства Checked на каждой итерации, вы всегда можете сделать:

bool checked = this.chkSelectAll.Checked;
for (int i = 0; i < this.listBoxColumns.Items.Count; i++)
{
    this.listBoxColumns.SetSelected(i, checked);
}

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

Answer 2

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

bool isChecked = this.chkSelectAll.Checked;
for (int i = 0; i < this.listBoxColumns.Items.Count; i++) {
    this.listBoxColumns.SetSelected(i, isChecked);
}

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

Answer 3

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

«Преждевременная оптимизация - корень всего зла»

Второе легко читаемо, так что просто пойдите с этим, если только позже не возникнет необходимость в оптимизации (что, на мой взгляд, маловероятно).

Answer 4

Любая разница в производительности будет незначительной.

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

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

Answer 5

Я не вижу существенной разницы в производительности между ними. Способ подтвердить это - установить эталонный тест и рассчитать время для разных алгоритмов на протяжении 1000 с итераций.

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

Лично я бы каждый раз заходил на второй подход. У вас есть только один цикл для обслуживания, и код понятнее.

Answer 6

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

Второй пример предпочтительнее, поскольку вы не повторяете код цикла.

Answer 7

Почему бы не использовать System.Diagnostics.StopWatch и сравнить их самостоятельно? Однако я не верю, что будет какая-то реальная разница в производительности. Первый пример может быть быстрее, потому что вы обращаетесь к chkSelectAll.Checked только один раз. Оба легко читаются, хотя.