Оптимизация кода с LedgerTrans

[Poleax]

Есть в Axapte 3 SP6 class LedgerRRGOperationBalanceTotal_RU метод

public AmountMST calc()
{
    AmountMST   sumTmp, balanceAmountMST;

    balanceAmountMST = 0;

    if (m_PEriodType == LedgerRRGBalancePeriodType_RU::Incoming)
        m_CalculateDate -=  1;

    while select  m_AccountList
    outer join    m_LedgerTrans
        where m_LedgerTrans.TransDate  <= m_CalculateDate          &&
              m_AccountList.AccountNum == m_LedgerTrans.AccountNum &&
              m_LedgerTrans.PeriodCode == PeriodCode::Regular
    {
        if (this.checkTransaction(m_LedgerTrans.TransType,
                                  m_LedgerTrans.OperationsTax,
                                  m_LedgerTrans.Correct,
                                  m_LedgerTrans.Dimension,
                                  ''))
        {
            if (m_currencyForCalc == LedgerRRGCurrencyForCalc_RU::AmountMST)
            {
                sumTmp = m_LedgerTrans.AmountMST;
            }
            else
            {
                sumTmp = m_LedgerTrans.AmountMSTSecond;
            }

            balanceAmountMST    += (m_AccountList.ReverseSign ? (-1) : 1) * sumTmp;
        }
    }

    return  balanceAmountMST;
}

Как его можно оптимизировать? Ощутимо долго цикл пробегается по LedgerTrans, да при этом еще вызывает postLoad каждый раз.

[mazzy]

Цитата:

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

Как его можно оптимизировать? Ощутимо долго цикл пробегается по LedgerTrans, да при этом еще вызывает postLoad каждый раз.

Во-первых, избавиться от outer join.
Во-вторых, прекратить извращение с суммированием от начала времен и использовать промежуточные итоги из LedgerBalancesDimTrans.

[raz]

В-третьих, использовать sum() и group by.

В-четвертых, перенести генератор из DAX 4.

[Poleax]

mazzy по вашему outer joint тут вообще не нужен?
raz

Цитата:

В-четвертых, перенести генератор из DAX 4.

вы уверены, что можно его из 4 в 3 перенести? Есть реализация?

[Poleax]

На сколько необходим вызов табличного метода postLoad() при каждом обращении к LedgerTrans ?
Деактивировать его можно или не нужно?

[raz]

public AmountMST calc()
{
    AmountMST   sumTmp, balanceAmountMST;

    balanceAmountMST = 0;

    if (m_PEriodType == LedgerRRGBalancePeriodType_RU::Incoming)
        m_CalculateDate -=  1;

    while select  m_AccountList
    while select  sum(AmountMST), sum(AmountMSTSecond) from m_LedgerTrans
        group by TransType, OperationsTax, Correct, Dimension
        where m_LedgerTrans.TransDate  <= m_CalculateDate          &&
              m_LedgerTrans.AccountNum == m_AccountList.AccountNum &&
              m_LedgerTrans.PeriodCode == PeriodCode::Regular
    {
        if (this.checkTransaction(m_LedgerTrans.TransType,
                                  m_LedgerTrans.OperationsTax,
                                  m_LedgerTrans.Correct,
                                  m_LedgerTrans.Dimension,
                                  ''))
        {
            if (m_currencyForCalc == LedgerRRGCurrencyForCalc_RU::AmountMST)
            {
                sumTmp = m_LedgerTrans.AmountMST;
            }
            else
            {
                sumTmp = m_LedgerTrans.AmountMSTSecond;
            }

            balanceAmountMST    += (m_AccountList.ReverseSign ? (-1) : 1) * sumTmp;
        }
    }

    return  balanceAmountMST;
}

Цитата:

вы уверены, что можно его из 4 в 3 перенести?

абсолютно уверен

[mazzy]

Цитата:

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

mazzy по вашему outer joint тут вообще не нужен?

Да.

[mazzy]

Цитата:

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

where m_LedgerTrans.TransDate <= m_CalculateDate &&

Это конечно, да...
Но снова суммирование идет от начала времен.

Разберитесь как суммирует класс LedgerBalanceDim_CurrentMST и все семейство LedgerBalance*

[glibs]

Цитата:

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

В-четвертых, перенести генератор из DAX 4.

Что верно, то верно.

Там одно только сокращение выбираемых для каждой записи полей само по себе уже даст ощутимый прирост производительности.

Но в 4.0 был реализован комплекс мер по повышению производительности. Глупо было бы не перенести. Тем более, что там функционал развивают.

[mazzy]

Цитата:

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

Там одно только сокращение выбираемых для каждой записи полей само по себе уже даст ощутимый прирост производительности.

Это да.
Но гораздо больший прирост даст отсутствие перехваченного метода postload, а следовательно запрос будет целиком исполняться на SQL-сервере

[glibs]

Цитата:

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

...
запрос будет целиком исполняться на SQL-сервере
...

А что в данном контексте нужно понимать под термином "запрос"?

[mazzy]

Цитата:

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

А что в данном контексте нужно понимать под термином "запрос"?

текстовая строка "Select <Бла-бла-бла> from <Бла-бла-бла> ...", которая выполняется НА СЕРВЕРЕ.

поскольку у таблицы LedgerTrans переопределен метод postLoad, то умная Аксапта не посылает SQL-серверу запрос с просьбой посуммировать, а выбирает все записи по одной, применяет к каждой метод postLoad и суммирует сама.

Поэтому для таблиц с перехваченным postLoad гораздо важнее сократить объем выборки, нежели делать агрегирование (raz, к великому сожалению для таблицы LeagerTrans ваш совет не очень помогает. Вот для других таблиц - да, очень полезный совет).


Так вот. Русские отчеты написаны неправильно. Они не учитывают "особенность" таблицы LedgerTrans и суммируют "от начала времен". Что приводит к выборке в Аксапту каждой проводки из LedgerTrans, которая попадает в условие.

Еще раз советую посмотреть как с этим вопросом справились в буржуйских финансовых отчетах. В буржуйских из LedgerTrans никогда не выбирается больше финансового периода - Большинство данных берется из промежуточных итогов. (надо также помнить, что финансовый период безболезненно можно разбить на несколько в случае чего)

[raz]

Цитата:

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

Поэтому для таблиц с перехваченным postLoad гораздо важнее сократить объем выборки, нежели делать агрегирование (raz, к великому сожалению для таблицы LeagerTrans ваш совет не очень помогает. Вот для других таблиц - да, очень полезный совет).

спорить не буду, но вот такой job:

static void Job1(Args _args)
{
    ledgertrans     lt;
    ;
    select sum(amountmst) from lt where lt.AccountNum == "zzz";
    print(lt.AmountMST);
    pause;
}

дал такой эффект (количество записей в LedgerTrans 8933031 количество суммируемых записей 438868)

[glibs]

Я тоже не буду спорить ...

Но если поставить брякпоинт в методе .postLoad(), то с помощью дебагера и счетных палочек можно убедиться, что этот вражеский метод вызывается для результата GROUP BY, а не для каждого LedgerTrans в отдельности.

[raz]

Цитата:

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

Я тоже не буду спорить ...

Но если поставить брякпоинт в методе .postLoad(), то с помощью дебагера и счетных палочек можно убедиться, что этот вражеский метод вызывается для результата GROUP BY, а не для каждого LedgerTrans в отдельности.

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

[glibs]

Вообще, тема относительно русских финотчетов уже была раскрыта...

Генератор финансовых отчётов

И даже обновление потом вышло.

[Poleax]

Какая интересная большая тема получилась.
Raz спасибо, твой код ускорил вывод отчета, с 3 часов до 12 минут.
P.S. Данные в отчетах одинаковые

glibs
Генератор финансовых отчётов

Цитата:

2. Не то, чтобы радикально, но факт. Как это ни банально, но создание кластерных индексов на таблицах LedgerRRGAccountInterval_RU, LedgerRRGCellTable_RU, LedgerRRGDimensionInterval_RU, LedgerRRGOffsetAccountInterval_RU, LedgerRRGOperationTable_RU повышает скорость выборки данных для отчета. Еще раз повторю, что не радикально. Можно сказать даже не существенно на фоне вышеописанного. Ну и поставить EntireTable кэш на LedgerRRGReportTable_RU равно как и группу таблиц Group какой-нибудь вместо Misc тоже не помешает.

Уточнить можно точный список полей для кластерного индекса, для каждой таблицы (LedgerRRGAccountInterval_RU, LedgerRRGCellTable_RU, LedgerRRGDimensionInterval_RU, LedgerRRGOffsetAccountInterval_RU, LedgerRRGOperationTable_RU )?

[mazzy]

Цитата:

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

спорить не буду, но...

Цитата:

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

Я тоже не буду спорить ...

Все бы так "не спорили"

Я тут было хотел съехидничать по поводу упрощения задачи, про то, что в изначальном методе были офигительные Group by... Но просто проверил. ax3.0sp6, ax4.0sp2, ax2009. Результат одинаковый:

Действительно группирует на сервере, невзирая на перекрытый метод PostLoad. Офигеть!

static void Job7(Args _args)
{
    ledgertrans     lt;
    ;
    while select sum(amountmst) from lt
    group by AccountNum, TransDate, PeriodCode, TransType, OperationsTax, Correct, Dimension
    where lt.AccountNum == "51.010"
    {
        print(lt.AmountMST);
    }
}

"Но ведь был же сарайчик" (С)...
Интересно, когда поменяли?
Ладно, спишем на мой старческий маразм.

Спасибо вам огромное.

Цитата:

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

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

Да.
raz, ты прав!

[mazzy]

Цитата:

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

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

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