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