Denis Trunin's Blogs: Blocking in D365FO(and why you shouldn't always follow MS recommendations)

[trud]

Цитата:

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

А как я понял мотивацию автора: "while select по умолчанию, а update_recordset только если нет другого выхода "

Ага, именно это и посыл поста, используем только когда нужно

Цитата:

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

Ну если эти поля совпадают с полями в индексе, то таки да, быстрее. А что, медленее ?

Вы реально не знаете или это просто флуд?

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2

CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");

[Logger]

Цитата:

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

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2

Интересно и какой же "канонический" ответ они ожидали услышать?

[ax_mct]

Цитата:

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

Интересно и какой же "канонический" ответ они ожидали услышать?

То что одинаково полагаю. Где-то на форуме было что все равно полная запись вернется если по ключевому полю. Уже не помню почему

[ax_mct]

Цитата:

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

Ага, именно это и посыл поста, используем только когда нужно

Вы реально не знаете или это просто флуд?

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2

CustTable       custTable;
        ;
        //1
        select AccountNum from custTable
            where custTable.AccountNum == "C-0000101";

        custTable = null;    
        //2
        custTable = custTable::find("C-0000101");

custTable = null; Это привычка или какой-то сакральный смысл?

[skuull]

Цитата:

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

Подобный вопрос обычно задавали при завершении стажировки в Коламбусе - какой вариант быстрее 1 или 2]

Одинаково медленно или одинаково быстро. Вы реально утверждаете, что стажер после 2 месяцев сможет внятно обьяснить почему ? Я думаю больше половины учасников этого форума не смогут сказать почему и когда будет по разному и т.д. и т.п. Тут даже есть отдельная секта верующих в вред кеша или в его неработоспособность.

[Pandasama]

Цитата:

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

Одинаково медленно или одинаково быстро.

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

[trud]

Цитата:

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

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?

Так а что мешает проверить?

Цитата:

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

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

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

Цитата:

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

и поэтому работать должно быстрее?

А если переменную назвать не "custTable", а "с" будет быстрее? (сорри за стеб)

Цитата:

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

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

А есть ссылка?

[Player1]

Цитата:

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

А есть ссылка?

"Попробуйте использовать список полей для выбора inventJournalTrans. Использовано только 2% размера записи."

Метка @SYS91289 используемая в SysBPCheckMemberFunction.checkUseOfFieldLists() с коментарием в коде //Less than half the bandwidth of fields are used
Такая ссылка устроит?

[skuull]

Цитата:

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

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Вроде в случае когда у нас указан набор полей, у нас меньше количество данных передаваемых между клиентом-сервером, и поэтому работать должно быстрее?

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля"

Поле, по которому выборка, ключевое и на таблице включен кеш. Бедная ах кеширует всю строку целиком поэтому выбирает все поля. Если бы вы использовали другое поле в where, к примеру, ourAccountnumber по которому есть индекс, но не уникальный, то полей в выборке было бы 2. А если поставить entire table кеш, то вообще все становится хорошо. Видите, это мы пока на уровне АХ, никакими пакетами и страницами мы ещё не разговариваем.

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

[Vadik]

Цитата:

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

А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?

Веронятно потому что в кэш (CacheLookup=Found) что-то кроме AccountNum положить надо? И потом как-то резолвить из него

Цитата:

Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля

Best practices это же не религиозные догмы, и мы инженеры а не последователи культа. Это рекомендации, их нужно понимать, применять осознанно и проверять. Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных). С Azure SQL это мне кажется еще менее актуально, тут скорее латентность и geographic redundancy кроют пропускную способность как бык овцу

trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?

[skuull]

Цитата:

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

Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных).

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

[fed]

Цитата:

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

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

Потому что указание списка полей может порождать очень интересные ошибки кодирования, потому что где-то ниже по коду обратились к полю, которое забыли прочитать. То есть - список полей полезно указывать только если:
1. Точно есть покрывающий индекс или есть не нужные нам BLOB поля.
2. Этот самый select выполняется в недрах какого-то очень критичного по времени участка (ну например если этот select выполняется 1M раз и из за структур данных мы не можем его в какой-то внешний while select добавить).
Во всех остальных случаях указание списка полей приводит к достаточно неощутимой оптимизации, но при этом повышает вероятность очень неприятных ошибок.

[skuull]

Цитата:

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

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

Любой код может содержать ошибки кодирования, так себе аргумент. Как не напиши, все равно умельцы все испортят и индексы ваши поломают и BLOB поля добавят и ваш код в цикл завернут и начнут крутить 1м раз, потом еще пальцам тыкать будут и говорить что он медленный. Так и до php не далеко.

Эта дискуссия имеет смысл только в случае, когда есть потребность сделать быстрее. Если мы пишем что-то что вызывается раз в году и обрабатывает 1 строку и так будет в обозримом будущем, то вообще все равно как оно написано. Но вот топикстартеру нет, он собирается вводить новые BP. А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.

[Vadik]

Цитата:

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

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

Для тиражируемого продукта, особенно если Вы единственный owner этого кода, или для критичного по производительности кода - да, почему бы и нет (хотя и тут "точно быстрее" требует уточнения "насколько быстрее"). Для проектной доработки "по месту", которую после тебя другие люди править будут, и к каким еще полям они обратятся и какие еще методы на таблице вызовут, и стоит этого вся эта оптимизация - вопрос на миллион

[trud]

Цитата:

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

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

Почему это будет быстрее то? ну т.е. диск у нас размечен секторами в 64КБ к примеру, он в любом случае прочитает все
По сети тоже пакет передается..
Где выигрыш то в скорости?

[Vadik]

Цитата:

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

Почему это будет быстрее то? ну т.е. диск у нас размечен секторами в 64КБ к примеру, он в любом случае прочитает все

Потому что гладиолус Key lookup (clustered) , а данные и некластерный индекс в разных экстентах лежат

[trud]

Цитата:

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

trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?

Пример упрощение того что было в реальной жизни. Создан по результатам анализа накладной по закупке с включенной корреспонденцией в 2012(тут была тема). Но с замечанием согласен, надо добавить именно реальный сценарий в D365. попробую поразношу накладные на досуге