Перечитываю тут на досуге "Рефакторинг" Фаулера.
Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
Главный пример — subj.
Автор предлагает следующий фрагемент кода
Интересно ваше мнение по поводу того, действительно ли стоит жертвовать производительностью (и не кешировать вычисления в таких случаях в угоду более красивому коду) и положиться на профайлер? Честно говоря, у меня рука бы дрогнула такое написать, но я уже начинаю сомневаться
Здравствуйте, Аноним, Вы писали:
А>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
А в чём причина думать, что это будет работать с разной скоростью?
> Перечитываю тут на досуге "Рефакторинг" Фаулера. > Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности. > > Главный пример — subj. > Автор предлагает следующий фрагемент кода > >
> > Интересно ваше мнение по поводу того, действительно ли стоит жертвовать производительностью (и не кешировать вычисления в таких случаях в угоду более красивому коду) и положиться на профайлер? Честно говоря, у меня рука бы дрогнула такое написать, но я уже начинаю сомневаться
Ну так как обычно — все зависит от конкретной ситуации. Когда-то можно пожертвовать производительностью, когда-то — нет.
А в приведенном примере одновременно ухудшается и читаемость, и производительность. Там разве что tmp как const double объявить имеет смысл, с точки зрения улучшения читаемости. Если уж совсем невмоготу — то поменять везде tmp на a_ * b_, а не на вызов функции.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Аноним, Вы писали:
А>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
А>Главный пример — subj. А>Автор предлагает следующий фрагемент кода
А>
А>Интересно ваше мнение по поводу того, действительно ли стоит жертвовать производительностью (и не кешировать вычисления в таких случаях в угоду более красивому коду) и положиться на профайлер? Честно говоря, у меня рука бы дрогнула такое написать, но я уже начинаю сомневаться
А>Спасибо!
поясните если неслжно неграмотному (нечитавшему еще Фаулера) смысл данного рефакторинга
Здравствуйте, Аноним, Вы писали:
А>Интересно ваше мнение по поводу того, действительно ли стоит жертвовать производительностью (и не кешировать вычисления в таких случаях в угоду более красивому коду) и положиться на профайлер? Честно говоря, у меня рука бы дрогнула такое написать, но я уже начинаю сомневаться
А>Спасибо!
Солидарен с тобой
"более красивый код" Фаулера фтопку
Здравствуйте, Аноним, Вы писали:
А>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
Невнимательно перечитывал
Там вполне логично написано, что не стоит заниматься оптимизацией зарание, пока этого не нужно. А нужно это или нет, можно узнать, только отпрофайлив код, и чем код более структурированный — тем легче находить будет в нем находить баттлнеки. Так что рефактори по максимому, а потом попрофайлив, оптимизируй узкие места. И как почти всегда бывает, узкие места оказываются далеко не там, где кажется по началу. И баттлнеки, при хорошо структурированном коде, гораздо легче оптимизировать, так как код локализирован.
"To protect people you must slay people. To let people live you must let people die. This is the true teaching of the sword."
-Seijuro Hiko, "Rurouni Kensin"
Re[2]: Replace temp with query
От:
Аноним
Дата:
06.03.07 11:29
Оценка:
Здравствуйте, remark, Вы писали:
А>>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
R>А в чём причина думать, что это будет работать с разной скоростью?
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, remark, Вы писали:
А>>>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>>>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
R>>А в чём причина думать, что это будет работать с разной скоростью?
А>Очевидно в том, что ab() будет вызываться дважды.
Если ab() вызывается дважды с т.з. абстрактной с++ машины, это ещё не значит, что будет хоть какая-то разница по времени выполнения.
Здравствуйте, Аноним, Вы писали:
А>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
А>Главный пример — subj. А>Автор предлагает следующий фрагемент кода
А>
А>Интересно ваше мнение по поводу того, действительно ли стоит жертвовать производительностью (и не кешировать вычисления в таких случаях в угоду более красивому коду) и положиться на профайлер? Честно говоря, у меня рука бы дрогнула такое написать, но я уже начинаю сомневаться
А>Спасибо!
Вне контекста невозможно ответить на вопрос с уверенностью, но у меня второй пример вызывает сильные подозрения.
В первом случае мы "замораживаем" состояние объекта и вычисляем на его основе результат. Во втором -- вызывем метод ab() котрый даже не объявлен const и непонятно что он делает.
Лучше уж рефакторить так (если вообще это нужно в данном примере в чем я сильно сомневаюсь)
Здравствуйте, sux, Вы писали:
sux>поясните если неслжно неграмотному (нечитавшему еще Фаулера) смысл данного рефакторинга
Смысл в том, чтобы избавиться от локальных переменных, сделать код нагляднее и уменьшить вероятность ошибки.
With regards,
Vladislav Lazarenko
Re[2]: Replace temp with query
От:
Аноним
Дата:
06.03.07 14:12
Оценка:
Здравствуйте, Sergey, Вы писали:
S>Ну так как обычно — все зависит от конкретной ситуации. Когда-то можно пожертвовать производительностью, когда-то — нет. S>А в приведенном примере одновременно ухудшается и читаемость, и производительность. Там разве что tmp как const double объявить имеет смысл, с точки зрения улучшения читаемости. Если уж совсем невмоготу — то поменять везде tmp на a_ * b_, а не на вызов функции.
Разницы в производительности тут скорее всего не будет, поскольку современные компилляторы с оптимизируют этот код. Скорее всего вызов функции будет заинлайнен.
-Владимир
Здравствуйте, Аноним, Вы писали:
А>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
Ещё раз поясню свою мысль:
struct A
{
double a_;
double b_;
double f()
{
double tmp = a_ * b_;
if (tmp > 10)
return tmp * 0.5;
else
return tmp;
}
};
struct B
{
double a_;
double b_;
double ab()
{
return a_ * b_;
}
double f()
{
if (ab() > 10)
return ab() * 0.5;
else
return ab();
}
};
int main()
{
A a = {rand(), rand()};
std::cout << a.f();
B b = {rand(), rand()};
std::cout << b.f();
}
Вывод: пишите как Вам удобнее/быстрее/хочется, покуда Вы записываете одно и то же поведение, нет никаких оснований полагать, что это будет выполняться медленнее или быстрее.
> S>Ну так как обычно — все зависит от конкретной ситуации. Когда-то можно пожертвовать производительностью, когда-то — нет. > S>А в приведенном примере одновременно ухудшается и читаемость, и производительность. Там разве что tmp как const double объявить имеет смысл, с точки зрения улучшения читаемости. Если уж совсем невмоготу — то поменять везде tmp на a_ * b_, а не на вызов функции. > > Разницы в производительности тут скорее всего не будет, поскольку современные компилляторы с оптимизируют этот код. Скорее всего вызов функции будет заинлайнен. > -Владимир
Вообще-то в примере функция была определена вне тела класса. Поэтому я предположил, что и объявлена она не как инлайн. Соответственно, есть хорошие шансы на падение производительности.
Posted via RSDN NNTP Server 2.0
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, remark, Вы писали:
А>>Перечитываю тут на досуге "Рефакторинг" Фаулера. А>>Никак не могу понять (скорее, "принять") некоторые рефакторинги, напрямую связанные с ухудшением производительности.
R>Ещё раз поясню свою мысль: