14.8. Соображения эффективности A

14.8. Соображения эффективности A

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

bool sufficient_funds( Account acct, double );

то при каждом ее вызове требуется выполнить почленную инициализацию формального параметра acct значением фактического аргумента-объекта класса Account. Если же функция имеет любую из таких сигнатур:

bool sufficient_funds( Account *pacct, double );

bool sufficient_funds( Account &acct, double );

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

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

// задача решается, но для больших матриц эффективность может

// оказаться неприемлемо низкой

Matrix

operator+( const Matrix& m1, const Matrix& m2 )

{

Matrix result;

// выполнить арифметические операции ...

return result;

}

Этот перегруженный оператор позволяет пользователю писать

Matrix a, b;

// ...

// в обоих случаях вызывается operator+()

Matrix c = a + b;

a = b + c;

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

Следующая пересмотренная реализация намного увеличивает скорость:

// более эффективно, но после возврата адрес оказывается недействительным

// это может привести к краху программы

Matrix&

operator+( const Matrix& m1, const Matrix& m2 )

{

Matrix result;

// выполнить сложение ...

return result;

}

но при этом происходят частые сбои программы. Дело в том, что значение переменной result не определено после выхода из функции, в которой она объявлена. (Мы возвращаем ссылку на локальный объект, который после возврата не существует.)

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

// нет возможности гарантировать отсутствие утечки памяти

// поскольку матрица может быть большой, утечки будут весьма заметными

Matrix&

operator+( const Matrix& m1, const Matrix& m2 )

{

Matrix *result = new Matrix;

// выполнить сложение ...

return *result;

}

Однако это неприемлемо: происходит большая утечка памяти, так как ни одна из частей программы не отвечает за применение оператора delete к объекту по окончании его использования.

Вместо оператора сложения лучше применять именованную функцию, которой в качестве третьего параметра передается ссылка, где следует сохранить результат:

// это обеспечивает нужную эффективность,

// но не является интуитивно понятным для пользователя

void

mat_add( Matrix &result,

const Matrix& m1, const Matrix& m3 )

{

// вычислить результат

}

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

// более не поддерживается

Matrix c = a + b;

и использовать их в выражениях:

// тоже не поддерживается

if ( a + b c ) ...

Неэффективный возврат объекта класса - слабое место С++. В качестве одного из решений предлагалось расширить язык, введя имя возвращаемого функцией объекта:

Matrix&

operator+( const Matrix& m1, const Matrix& m2 )

name result

{

Matrix result;

// ...

return result;

}

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

// переписанная компилятором функция

// в случае принятия предлагавшегося расширения языка

void

operator+( Matrix &result, const Matrix& m1, const Matrix& m2 )

name result

{

// вычислить результат

}

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

Matrix c = a + b;

было бы трансформировано в

Matrix c;

operator+(c, a, b);

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

classType

functionName( paramList )

{

classType namedResult;

// выполнить какие-то действия ...

return namedResult;

}

то компилятор самостоятельно трансформирует как саму функцию, так и все обращения к ней:

void

functionName( classType &namedResult, paramList )

{

// вычислить результат и разместить его по адресу namedResult

}

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

И последнее замечание об эффективности работы с объектами в C++. Инициализация объекта класса вида

Matrix c = a + b;

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

Matrix c;

c = a + b;

но объем требуемых вычислений значительно больше. Аналогично эффективнее писать:

for ( int ix = 0; ix

чем

Matrix matSum;

for ( int ix = 0; ix

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

Point3d p3 = operator+( p1, p2 );

можно безопасно трансформировать:

// Псевдокод на C++

Point3d p3;

operator+( p3, p1, p2 );

преобразование

Point3d p3;

p3 = operator+( p1, p2 );

в

// Псевдокод на C++

// небезопасно в случае присваивания

operator+( p3, p1, p2 );

небезопасно.

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

Что касается инициализируемого объекта, то отведенная под него память еще не подвергалась обработке. Если же объекту присваивается значение и в классе объявлены конструкторы (а именно этот случай мы и рассматриваем), можно утверждать, что эта память уже форматировалась одним из них, так что непосредственно передавать объект функции небезопасно.

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

Point3d p3;

p3 = operator+( p1, p2 );

трансформируется в такой:

// Псевдокод на C++

Point3d temp;

operator+( temp, p1, p2 );

p3.Point3d::operator=( temp );

temp.Point3d::~Point3d();

Майкл Тиманн (Michael Tiemann), автор компилятора GNU C++, предложил назвать это расширение языка именованным возвращаемым значением (return value language extension). Его точка зрения изложена в работе [LIPPMAN96b]. В нашей книге “Inside the C++ Object Model” ([LIPPMAN96a]) приводится детальное обсуждение затронутых в этой главе тем.

2012-11-28 08:45:13 vertical

эффективнее писать: for ( int ix = 0; ix size-2; ++ix ) { Matrix matSum = mat[ix] + mat[ix+1]; // ... } чем Matrix matSum; for ( int ix = 0; ix size-2; ++ix ) { matSum = mat[ix] + mat[ix+1]; // ... } Не всегда. На каждой итерации цикла будет создаваться и уничтожаться объект matSum. Тут производительность зависит еще и от вычислительной сложности конструктора и деструктора объекта.

2012-10-19 15:36:29 Ярослав

Спасибо, очень содержательно!