Цитата:
Сообщение от
Masel
Я тут в очередной раз занимался оптимизацией разноски розничных продаж и наткнулся еще на пару возможных улучшений.
<...>
2. В классе Tax метод lineTaxAmount. В начале метода проверяется что в таблице есть записи немного экзотическим методом, считая их количество. Я поменял так, хотя можно было наверное вообще убрать запрос, меня пока и так устраивает.
X++:
if (this.taxParameters().TaxSpecifyLine)
{
if (this.taxParameters().TaxSpecifyLine)
{
//+ sergey.m 03.02.2022 FRE_20421639_001
//select count(RecId) from taxWorkTrans;
select firstOnly RecId from taxWorkTrans;
//- sergey.m 03.02.2022 FRE_20421639_001
if (taxWorkTrans.RecId > 0 && !this.useSubLedgerJournalLines())
{
// Posting out of TmpTaxWorkTrans
Нашел еще одно место, где наличие записей через select count делается:
\Classes\TaxPost\saveAndPost
X++:
public void saveAndPost(LedgerPostingController _ledgerPostingController, SelectableDataArea _companyToPost = curext())
{
this.initLedgerPosting(_ledgerPostingController);
//+ Abramov_ 27.05.2022 TSK0000280_08
//select count(RecId) from taxWorkTrans;
select firstonly RecId from taxWorkTrans;
//- Abramov_ 27.05.2022 TSK0000280_08
if (taxWorkTrans.RecId > 0 && !this.useSubLedgerJournalLines())
Еще маленькая оптимизация:
При создании строк накладной покупки в PurchInvoiceJournalCreate.createJournalLine() поле vendInvoiceTrans.LineAmount рассчитывается без учета экземпляра класса Tax, который был рассчитан на предыдущем шаге (в PurchInvoiceJournalCreate.initTotals()).
Т.е. в initTotals мы формируем кэш проводок TaxUncommitted, и, если не передать Tax, мы делаем лишние запросы к тому же TaxUncommitted.
X++:
//+ Abramov_ 27.05.2022 TSK0000280_08
//vendInvoiceTrans.LineAmount = vendInvoiceInfoLine.lineAmountExclTax(vendInvoiceJour.InvoiceDate);
vendInvoiceTrans.LineAmount = vendInvoiceInfoLine.lineAmountExclTax(vendInvoiceJour.InvoiceDate, this.parmTax());
//- Abramov_ 27.05.2022 TSK0000280_08
Еще мы решили в таблицах TmpTaxWorkTrans и TaxUncommitted установить св-во SaveContents = NO полям, которые относятся к функциональности других стран (напр. _IN, _BR). Их оказалось довольно много, TmpTaxWorkTrans "похудел" на треть.
Еще мы провели эксперимент с переводом TmpTaxWorkTrans в TempDB (и обновлением существующей функциональности соответственно). Пришли к выводу, что без существенного рефакторинга кода от версии TmpTaxWorkTrans в TempDB толку нет, т.к. производительность расчета налогов упала ровно в два раза.