Нужно ли делать условие перед вызовом метода для избежания выделения дополнительной памяти?

Question

[ant123455432143]

Всем привет! Сделал задачу на php и коллега оставил замечание. Вот упрощенный пример кода:

private function setIsTestProperty(bool $isTest): void
{
  if (!$isTest) {
    return;
  }
 
  $this->orderIsTest>setValue('Y');
}

И вызов этого метода:

$isTestOrder = $this->getIsTest();
$this->setIsTestProperty(!is_null($isTestOrder));

Коллега говорит:
"Может лучше сделать проверку перед вызовом метода? При передаче параметра внутрь метода под него выделяется дополнительная память."

if ($isTestOrder)
$this->setIsTestProperty();

Тимлид говорит, что это экономия на спичках и так делать не нужно. Кто прав? Мне нужно аргументировать ответ, но я не знаю как ответить правильно.

Comments

[ant123455432143]

Ипатьев, ThunderCat, попросил его показать источник, который показывает, что его способ добавляет производительность, он написал, что:

1) Вызывается метод (тратится процессорное время и память)
2) В него передается переменная (тратится дополнительная память)
3) Внутри метода обрабатывается условие-проверка переменной
При этом метод с переменной вызывается абсолютно для всех заказов, в том числе не тестовых, которых большинство.

[Ипатьев]

Покажите мне код проекта, и я на спор найду в нем участок, который тратит ресурсов в тысячу раз больше, чем вот этот вызов. Но который при этом все равно ни на что не влияет.

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

[ThunderCat]

попросил его показать источник, который показывает, что его способ добавляет производительность,

То есть источник не показал, ограничившись маханием языком? Ну так я тоже так могу...

Цифрами - цикл на 10 000 вызовов с условием и без, и когда разница будет хотя бы 10 секунд, а потребление памяти в несколько раз меньше, тогда есть смысл о чем то говорить. А п... редполагать - не мешки таскать...

Может товарисч окажется прав, по тому что внутри метода еще 50 запросв в бд и 4 вызова сторонних апи...

Answer 1

[Ипатьев]

Если говорить про конкретный пример, то он просто бессмысленный, даже с точки зрения житейской логики.
Учитывая, что if ($isTestOrder) можно прочитать, как ЕСЛИ переменная не занимает памяти то проверка выглядит просто глупостью. "Если переменная не занимает памяти, то не передавать её. Так мы с экономим память!" Если переменная и так не занимает никакой памяти, то какого еще дополнительно выделения памяти она может потребовать?

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

В общем случае тут не будет никакой экономии, ни на спичках, ни без.

При передаче параметра внутрь метода под него выделяется дополнительная память

- это чушь и неправда.

При передаче в функцию параметра, который в принципе может занимать хоть какую-то осмысленную память (то есть не числа, не булева значения, и не null), память под него НЕ выделяется.

• Объекты изначально передаются по ссылке
  
• Строки и массивы - с использованием механизма copy-on-write. Что означает, что память будет выделяться только если переданное значение будет изменено в процессе обработки. А если оно будет только считываться, то дополнительной памяти занимать не будет
  

Для всех остальных типов, как было правильно сказано тимлидом - это будет экономия на спичках.

Comments

[ant123455432143]

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

[Ипатьев]

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

[ant123455432143]

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

[Ипатьев]

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

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

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

[Stalker_RED]

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

Но обычно читаемость и единство стиля в проекте важнее, чем размышления рядового кодера о производительности, и да - правильнее делать так, как скажет лид.

[Ипатьев]

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

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

Но обычно читаемость и единство стиля в проекте важнее, чем размышления рядового кодера о производительности, и да - правильнее делать так, как скажет лид.

А вот тут я на 100% согласен

Answer 2

[ThunderCat]

Мне нужно аргументировать ответ, но я не знаю как ответить правильно.

Очень просто: Так как проверка отнимает процессорное время, то экономия все равно будет липовой, вместо памяти потратится ресурс процессора. Сколь ни будь значительной экономии это не даст ни в том, ни в другом случае, точнее экономия будет в случае отсутствия проверки и существования переменной, что будет происходить скорее всего чаще чем несуществование переменной, ну или по крайней мере в каком-то числе случаев, в то время как проверка будет осуществляться всегда.

Answer 3

[Ивор Барханский]

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