Какую самую нелепую пессимизацию вы видели? [закрыто]

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

.

if( CurrentUser.CurrentRole == "Role1" || CurrentUser.CurrentRole == "Role2")  
{
// Access denied
} 
else
{
// Access granted
}

вместо

if( !CurrentUser.CurrentRole.equals("Admin") ) 
{
 // access denied
}  

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

Тот же коллега был также соединениями для производства и архивной таблицей для всех запросов.

Другой необычный прием производительности :)

if (!loadFromDb().isEmpty) {
    resultList = loadFromDb();
    // do something with results
}

За маленькую цену дополнительного хита DB Вы экономите все то время, делая как 10 строк кода, которые, вероятно, не сделали бы многого в пустом списке так или иначе. И вещи как это были рассеяны на всем протяжении кода :)

Я собирался упомянуть, что StringBuilder для tiny/non-looping представляют в виде строки concats, но его упомянутый.

Помещение переменных метода в частных участников класса для препятствования им то, чтобы быть " собранным "мусор" каждый раз выполнения метода". Переменные являются типами значения.

Приложение, которое привыкло поле Integer для выделенного, поразрядного, к которому группировки доступа к приложению наши клиенты могли добавить своих пользователей. Это означало в то время, когда мы могли создать общий итог 32 групп, чтобы быть совместно использованными через все 500 + клиенты.

Aaaah, но поразрядное сравнение быстрее, чем равняние и waaay быстрее, чем право соединения?

К сожалению, когда я полностью (и скорее устно) взбесился в этом коде, и это - автор, я обнаружил, что автор был моим боссом боссов. Довольно авторитарный чувак это складывается.

P.s.

Я знаю то, что Ваш думают, это полностью должно было быть право двоичной строки?:)

Многие программисты не знают или не хотят знать SQL, поэтому они находят «хитрости», которых следует избегать действительно с помощью SQL, чтобы они могли получить данные в массив. Массивы делают некоторых людей счастливыми. (Мне нравятся как курсоры, так и массивы. Coke и Pepsi.) Я нашел эти два блока кода в коде нескольких объектно-ориентированных программистов, который жаловался на медлительность реляционных баз данных. (ответ - не больше памяти или больше процессоров.)

Таблица в этом случае - огромная таблица с uniqueid_col - уникальным идентификатором или уникальной строкой.

Загрузите эти данные в arrayX (потому что массивы должны быть быстрее )

   Select uniqueid_col, col2, col3
     from super_big_tbl
 

(код псевдо)

Loop 
   arrayX.next_record
    if uniqueid_col = '829-39-3984'
      return col2
    end if
end loop
 

(Мой ответ внизу.)

Следующая ошибка - простая ошибка, которую я также видел. Идея в том, что вы никогда не получите дубликат таким образом:

   Select uniqueid_col, col2, col3
     from super_big_tbl
 group by uniqueid_col, col2, col3
   having uniqueid_col = '829-39-3984'

Правильный синтаксис должен быть

   Select uniqueid_col, col2, col3
     from super_big_tbl
    where uniqueid_col = '829-39-3984'
   

Любое значительное усилие по оптимизации, которое не основано на сортированных отчетах от инструмента профилировщика, зарабатывает большой WTF от меня.

Некоторые мои коллеги, которые были на проекте "оптимизации" существующих серверных пакетов (записаны в C++), "оптимизированный" до смерти регистрирующийся класс (!), с помощью win32-определенного кода и функций.

Возможно, узкое место было в logger.write (...), кто знает...

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

• Коллекции карт или "словари"
  Обычно в них используется какое-то хеш-кодирование, поэтому они будут иметь производительность O (1), но не будут работать даже при заполнении гораздо большим количеством элементов, чем обычно используется.

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

• Уведомления и обработка событий как способ сохранения согласованности данных
  Поскольку структура данных редко нормализуется, необходимо управлять несогласованностью, и уведомление является обычным методом, поскольку он якобы решает проблему «немедленно». Однако есть большая разница между оперативностью и эффективностью. Также «свойства», когда они Get или Set, поощряются проникать глубоко в структуру данных, чтобы попытаться сохранить ее согласованность. Эти методы «короткого поводка» могут привести к большим потерям вычислений. Методы «длинного поводка», такие как периодическое циклическое прохождение структуры данных для «восстановления», могут быть немного менее «немедленными», но гораздо более эффективными.

Примеры

У меня есть намеренная ... Однажды я реализовал сортировку с возвратом ... просто как доказательство концепции;)) Само собой разумеется, ее производительность была ужасной.