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