34.3.2 Оптимизация индексированного присваивания

Всеобъемлющая семантика леничной копирования по значению в Octave создает проблему производительности для методов пользовательских subsasgn. Представьте следующий вызов subsasgn

ss = substruct ("()", {1});
x = subsasgn (x, ss, 1);

где соответствующий метод выглядит так:

function x = subsasgn (x, ss, val)
  …
  x.myfield (ss.subs{1}) = val;
endfunction

Проблема заключается в том, что при входе в метод subsasgn, x все еще ссылается из области видимости вызывающего кода, что означает, что метод сначала должен разделить (скопировать) x и x.myfield перед выполнением присваивания. По завершении вызова, если ошибка не произошла, результат немедленно присваивается x в области видимости вызывающего кода, так что предыдущее значение x.myfield забывается. Таким образом, язык Octave подразумевает копирование N элементов (N — размер x.myfield), тогда как для изменения всего одного элемента достаточно. Другими словами, операция с постоянной временной сложностью снижается до линейной. Это может быть реальной проблемой для пользовательских классов, которые по своей природе хранят большие массивы.

Для частичного решения этой проблемы Octave использует специальную оптимизацию для методов пользовательских subsasgn, закодированных в файлах m-функций. Когда метод вызывается в результате встроенной синтаксической конструкции присваивания (не непосредственный вызов subsasgn, как показано выше), т. е. x(1) = 1, И если метод subsasgn объявлен с идентичными входными и выходными аргументами, как в примере выше, тогда Octave проигнорирует копирование x внутри области видимости вызывающего кода; следовательно, любые изменения, внесенные в x во время выполнения метода, будут напрямую влиять на копию вызывающего кода. Это позволяет, например, определять класс полиномов, где изменение одного элемента занимает постоянное время.

Важно понимать последствия этой оптимизации. Поскольку дополнительной копии x в области видимости вызывающего кода не будет, исключительно ответственность вызываемого кода не оставлять x в недопустимом состоянии, если во время выполнения произойдет ошибка. Кроме того, если метод частично изменит x и затем произойдет ошибка, эти изменения будут влиять на x в области видимости вызывающего кода. Удаление или полная замена x внутри subsasgn ничего не сделает, однако важны только индексированные присваивания.

Поскольку эта оптимизация может изменить работу кода (особенно если он плохо написан), функция optimize_subsasgn_calls предоставляется для ее управления. Эта функция включена по умолчанию. Еще один способ избежать оптимизации — объявить методы subsasgn с разными выходными и входными аргументами, например так:

function y = subsasgn (x, ss, val)
  …
endfunction