Поклон спецам от новичка. Где бы найти инфу по сабжу? Во всех перфоманс гайдах написано - use field-symbols... Насколько это хорошо с assigning в принципе понятно, но когда происходит
assign () to <fs>
в среде из сотен переменных и таблиц, я подозреваю что это не самый оптимальный подход, особенно если это цикл импорта файла с разнородными данными...

Продолжаю дальше - в принципе вариантов кроме приемов динамического программирования в задачке пока нету. Даст ли прирост производительности подход прекомпиляции динамических процедур с последующим вызовом в цикле? Самих динамических процедур ожидается вплоть до двух десятков. Уточняющий вопрос - уместно ли вообще здесь слово "компиляция", т.к. я не знаю каким образом сохраняются и исполняются динамически сформированные проги.

И общий вопрос - хочется почитать что-либо про глубокие внутренности ABAP'а. С курсом 490 и performance examples ознакомился, но хочется более фундаментальных знаний, чем шаблонные рекомендации. Устройство строк, таблиц, runtime environment и т.д. Гугление ничего не дает.

Зачем все это новичку? 1. в программировании не первый год 2. первая же задачка - оптимизация скорости уже сделанной программы. Спасибо!

golomeen, а как связаны "assign () to <fs>" и "в среде из сотен переменных и таблиц"?
Опишите вашу задачу. Не совсем понятно что вы хотите оптимизировать и какие динамические процедуры использовать.

В общем случае использование field-symbols первый и самый простой пункт в оптимизации производительности.
Динамическое программирование же к оптимизации не относится никаким боком. Это более читаемый и компактный код. Но не быстрый.

С фундаментальными знаниями не все просто. Отдельного нормального источника нет. По кускам много всего есть на help.sap.com, sdn.sap.com и в курсах.

Описываю. Реализован динамический мэппинг входных данных из csv-подобного файла (как уже сказано, разнородного) на основании кода записи. По нему определяется, в какую таблицу все будет ложиться. Пример

tables:
ZTABLE1, ZTABLE2, ... ZTABLEN.
...
FIELD-SYMBOLS :
<myfs> type any.
DATA:
my_fs_locator type STRING.
...
ASSIGN (my_fs_locator) TO <myfs>.
....
INSERT (my_fs_locator) FROM <myfs>.

в my_fs_locator перед выполнением assign может оказаться имя любой из таблиц перечисленных в начале. таблиц 2 десятка, на каждую как минимум дополнительная внутренняя + своя WA и еще тьма других переменных как локальных, так и глобальных из разных пулов. спрашивается - сколько assign будет искать эту несчастную таблицу в этой куче.
не лучше ли склеить 'assign ', my_fs_locator, ' to <myfs>' , несколько других строк (они касаются уже полей таблиц) и выполнять это подпрограммой? впрочем в таком коде скорее всего вообще не останется assign, либо как минимум <myfs> обретет конкретный тип нужной таблицы, короче код будет составлен максимально специфично.

Если Вы <я не знать русский языка>, то тогда ещё раз и внимательно перечитайте курс 490 - рекомендации может и шаблонные, но при грамотном применении дают реальный эффект. А вот всякое там "устройство строк, таблиц, runtime environment и т.д." чистая теория и мало где может быть применено практически. Вот поэтому и гугление ничего не дает.

sy-uname
не отрицаю полезности и нетленности 490 курса, но проблема этого assign съела мне весь мозг а в коде есть еще и тьма assign component. я слишком хорошо представляю какие тормоза это дает в классике типа C++/Delphi поэтому жду-не дождусь узнать, как избежать этого в ABAP
Еще один аргумент взяться именно за assign, а не прочую нетленку - кусок с assign самая базовая и повторяющаяся часть всего процесса.

Думаю никак, ибо это не проблема АБАП, а общее протиовречие любого программирования: Либо гибко - либо быстро!

разница с into есть, и в ряде случаев не в пользу assign/get reference,
но там такие микросекунды, что на фоне сопутствующих вызовов такая оптимизация погоды не сделает.

imho, лучше попытаться оптимизировать алгоритм целиком,
а если явных вариантов оптимизации нет, значит все как надо

Вы гадаете или профайлер вам показал тормоза?
Вы 100% уверены что тормоза не в базе данных? Что нет лишних селектов\инсертов? Что все циклы у Вас оптимальны и нет лишних чтений из таблиц?
Нет лишних перекладываний и пр?
И забудьте, свершенно забудьте C++/Delphi. Здесь Вам не там. Довольно разные среды.

тогда ответьте мне на до ужаса простой вопрос
кто быстрее
assign TABLE1 to <fs>
или
assign 'TABLE1' to <fs>
или
myvar = 'TABLE1'
assign (myvar) to <fs>

начальные условия остаются - tables TABLE1 - одна из сотен разнообразных таблиц, переменных и т.д. и т.п.

символьная сноска замедляет assign,
если укажете ее в lower-case, то станет еще медленнее

imho, через пару дней "отпустит"

я прекрасно понимаю что байт код и pure x86 вещи кардинально разные. но догадываюсь, что поиск по строке в окружении и обращение по точному адресу хоть на VM хоть на настоящем CPU должно отличаться в десятки раз по скорости. Вопрос в том что я не уверен ни в "поиск по строке в окружении" ни в "обращение по точному адресу" как методах выполнения того или иного кода на ABAP VM.

вот спасибо, наконец-то

осталось разузнать про компляцию. покамест разбор разных типов строк не захардкоден заранее, есть мысль "хардкодить" его динамически на основании данных мэппинговой таблицы. даст оно мне что-то или нет?

imho,
оптимизация которая дает до 10-15% от общего времени выполнения является несущественной,
т.е. код может быть и не идеален, но главное что он давно работает и кем-то отлажен.
если оптимизация усложняет код, то может лучше так и не оптимизировать,
чтобы потом не страдать от внезапно напавшей икоты.
для успокоения, можете полистать исходники стандартного функционала

Это даст Большое спасибо от всех тех, кто эту "динамику" в дальнейшем будет сопровождать.
Учтите, генерация требует времени. Формирование текста на основе некоторых данных требует времени. Количество попыток генерации ограничено и не очень велико.
И ещё раз - предположу что INSERT-ы в цикле съедают больше времени, чем здержки на ASSIGN.
Кстати, Вы не думали над распараллеливанием алгоритма?

мысль понятна умножать умноженное до меня лучше не буду.
инсертов уже куча локализована

в стандартном функционале только от into corresponding уже фигово

распараллелю обязательно когда одолею инсерты

всем спасибо