Никто не сталкивался с такой проблемой, что при вызове alv-списка, программа отъедает памяти в несколько раз больше, чем до вызова?
В моем случае ALV вызывается так:



Размер таблицы result - 300 Мб; перед вызовом эту же цифру показывает SM04. После вызова (но до выхода из ALV, т.е. до возврата из ФМ 'REUSE_ALV_GRID_DISPLAY'), SM 04 показывает 1900Мб. После выхода из ФМ - опять 300 Мб.

В чем тут может быть дело?

Дело в самом ALV. На каждую ячейку выводимой таблицы заполняется строка с типом LVC_S_DATA. За "красивости" платим памятью.

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

А может быть не стоит сразу выводить такую огромную таблицу пользователю? Что он будет с ней делать? Может дать возможность уточнять выборку и "проваливаться"?

Это да, но проблема в том, что alv все-равно потребляет памяти в 6 раз больше, чем размер передаваемой ему таблицы.

используйте ALV_LIST, оно и записей держит больше

А нет способов оптимизации или ограничение идет только по количеству строк, как в примерах SLIS?

А если нужно по работе пользователей такое кол-во строк? Что делать?

Любаша, а если не секрет, зачем например пользователю нужно 100 тыс строк? Наверно только чтобы посмотреть итоги, верно? Так в этом случае достаточно сделать консолидацию по какому-нибудь полю и ввести галку "Консолидировать по ..." на селекционный экран.

Дела в том, что у меня грид уже сейчас, на тесте имеет 6000 строк и это ещё цветочки. Так поставлена задача. Вчера выяснила, что у него есть ограничение и на кол-во столбцов - их должно быть 99, а у меня было заложено 124. Теперь буду бороться с этим.

Я столько вложила сил в этот грид - и такой облом с памятью и быстодействием! Помогите, плиз!!!

Конечно, будем думать с нашими консультаттами над уменьшением строк в выборке. Это - основное. Надо это согласовыыать с пользователями. А они хотят, как в EXCEL. Вот и весь секрет.

Любаша, тык может формировать файл локально в формате scv и открывать в Excel? Это должно быть быстро.
Вы сами говорите, что хотят, как в Excel, примочек alv им не надо.

А вносить в него изменения и затем записывать их в Z-таблицы?

Дык это уже не как в Excel.
Значит Вы еще и редактирование ALV открываете, а это дополнительные накладные расходы, imho.

Может тогда alv избавить от редакирования, а при двойном щелчке на строку вызывать форму для заполнения полей? Может это уменьшит размер alv, хотя бы за счет того, что не надо выводить 99 колонок.

Кстати, подскажите простыми словами, что такое в методе
?

обязательно передавать такую широкую таблицу? может формировать ее динамически?

про буфер:

http://sapboard.ru/forum/viewtopic.php ... 311781bed7

еще раз повторюсь, может использовать ALV_LIST ? такая широкая ALV_GRID да с огромным чистом записей естественно будет тормозить.

Сформировал структуру таблицы динамически - памяти стало жрать гораздо меньше.
Однако, это отменяет дефекта в ALV: контейнер, потребляющий в 7 раз больше памяти, чем его содержимое - это ненормально.

Писал по этому поводу в сап. Они утверждают, что в базисе 6.40 делались какие-то улучшения связанные с ALV. У нас - 6.20.