Оптимизация класса Tax

[mazzy]

Цитата:

Сообщение от Masel

На R2 в енуме 4 значения. У вас их больше либо потому, что R3, либо потому, что добавлено на USR слое.

R3

Цитата:

Сообщение от Masel

Вы в принципе не совсем понимаете в чем затыки по производительности в этом месте

Цитата:

Сообщение от Masel

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

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

Цитата:

Сообщение от Masel

То есть она создает абсолютно новую структуру данных и переваливает потом все элементы в цикле по одному. В пером параметре _first куча элементов, во втором немного.

Угу.

Цитата:

Сообщение от Masel

Здесь идеально бы работало просто

this.addCollections(_first, _second);
return _first;

Но тогда вы измените taxTransactionRelationshipCollection на которую ссылаются из других мест.

Угу-угу.

Цитата:

Сообщение от Masel

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

угу-угу-угу.
авторы россикского класса вот тоже побоялись.

Цитата:

Сообщение от Masel

Далее встает вопрос, как переделать так, чтобы оставить такой подход - два элемента скопировать в первый, но сделать это быстро.

Нужно что-то типа _first.Clone(). Но такого метода ни у Map, ни у Set нету. pack/unpack не решают задачу.

tmpTable.setTmpData(fromTmpTable);



по поводу pack/unpack создал отдельную тему
List/Set/Map/Array: deep clone через pack/create в классических Аксаптах

Цитата:

Сообщение от Masel

В качестве решения предлагается изменить структуру хранения так, чтобы дублирование выполнялось командой container1 = container2, это работает быстро. А для того, чтобы изменить интерфейс работы с классом модифицировать taxTransactionRelationshipCollection метод, чтобы он выдавал данные в привичном виде, собирая из контейнеров результат.

да, это я понял.
и огромное вам спаибо за предложенное решение.

но решить можно еще лучше.

прежде всего, потому что у вас нет организационных ограничений. В Майкрософте каждый объект АОТ приписан к определенной команде. И разработчик другой команды не имеет права менять чужой объект без согласования. Поэтому разработчики Московской команды часто вынуждены делать странные решения сбоку, вместо того, чтобы просто расширить функционал другого объекта АОТ.

У вас таких ограничений нет - вы можете менять любой класс, любую таблицу, любой объект АОТ.
Очень многие странности в Аксапте можно решить просто перенеся функционал в другой класс.
Вот такая вот организация труда у них там в Майкрософте.

Подумайте - а что если бы метод merge существовал прямо в классе с идиотским назвнием LedgerPostingOneToManyCollection?

Цитата:

Сообщение от Masel

По поводу идеи с таблицей. Будет тормозить еще больше я думаю, хотя не пробовал. В CIL точно больше.

Подумайте
Подумайте не только об этом месте.

Ведь по сути, данное место просто окрашивает движения разными enum-признаками. Рано или поздно эти признаки надо будет как-то связать с исходными движениями.

Поскольку сейчас признаки хранятся в коллекции, то надо будет снова делать цикл по одному и искать исходные движения по одному.
А можно было бы сделать select-join со временной таблицей

Похоже, что беда в том, что данный код класса с идиотским названием делал человек, который не знает ни аксапту, ни СУБД. Причем, этот код прошел ревью. Т.е. либо это был team lead, который может впендюрить код без ревью, либо вся команда была уровня "не знаю ни аксапту, ни СУБД". И я даже не знаю какой вариант хуже...

Цитата:

Сообщение от Masel

Вместо 4 контейнеров можно было сделать один, который бы хранил и RecId и enum.

а можно map как в исходном классе с идиотским названием LedgerPostingOneToManyCollection

Цитата:

Сообщение от Masel

Можно еще как-то по другому делать, например я думал использовать структуры .Net.

это только для CIL.
между p-code и .net слишком дорогой маршаллинг.

Цитата:

Сообщение от Masel

Или, возможно если оставить эти пробеги в циклах по Map, но просто убрать Set, то этого будет достаточно (заменить Map recId -> Set, на более простую структуру данных).

угу. таблицу, например

Цитата:

Сообщение от Masel

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

Если устраивает, то нет вопросов, конечно.

Огромное спасибо за предложенное решение.

[Masel]

Цитата:

Сообщение от mazzy

tmpTable.setTmpData(fromTmpTable);

Это не дублирование, вы просто получите вторую ссылку на тот же экземпляр таблицы.

Цитата:

Сообщение от mazzy

Подумайте - а что если бы метод merge существовал прямо в классе с идиотским назвнием LedgerPostingOneToManyCollection

Я если честно не понимаю просто эту идею, что это даст.

[mazzy]

Цитата:

Сообщение от Masel

Это не дублирование, вы просто получите вторую ссылку на тот же экземпляр таблицы.

вы ошибаетесь

Цитата:

Сообщение от Masel

Я если честно не понимаю просто эту идею, что это даст.

доступ к приватной переменной map
и возможность напрямую использовать методы этого map, вместо публичного интерфейса.

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

[Masel]

Цитата:

Сообщение от mazzy

вы ошибаетесь

Да нет, вроде не ошибаюсь. Такой джоб у меня выдает 2 записи и в 2012 и в d365. Два курсора по одной таблице. Вставляете в любой, получаете записи в обоих курсорах.

    TmpFrmVirtual tmp1, tmp2;
    
    tmp1.clear();
    tmp1.ItemId = 'item1';
    tmp1.insert();
    
    tmp2.setTmpData(tmp1);
    
    tmp2.clear();
    tmp2.ItemId = 'item2';
    tmp2.insert();    
   
    select count(RecId) from tmp1;
    info(strFmt("%1", tmp1.recId));