AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX Blogs
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 01.02.2019, 08:45   #21  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от trud Посмотреть сообщение
Ну главная идея была дать понять, что любую вещь связанную с производительностью надо проверять. Т.е. обычно отвечали что меньше полей, значит запрос меньше. А как посмотреть посмотреть запрос - ну включить трассировку - ну давай посмотрим... смотрим - они одинаковы
Надо проверять больше чем на 1 примере! Так вы реально утверждаете, что стажер после 2 месяцев сможет внятно обьяснить почему ?
Извините, что два раза спрашиваю, но уж хочется понять зачем там этот отсыл к стажёру.

Последний раз редактировалось skuull; 01.02.2019 в 08:54.
Старый 01.02.2019, 09:01   #22  
Player1 is offline
Player1
Участник
Самостоятельные клиенты AX
 
279 / 136 (5) +++++
Регистрация: 21.04.2008
Цитата:
Сообщение от trud Посмотреть сообщение
А есть ссылка?
"Попробуйте использовать список полей для выбора inventJournalTrans. Использовано только 2% размера записи."

Метка @SYS91289 используемая в SysBPCheckMemberFunction.checkUseOfFieldLists() с коментарием в коде //Less than half the bandwidth of fields are used
Такая ссылка устроит?
Старый 01.02.2019, 09:05   #23  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,426 / 1549 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Pandasama Посмотреть сообщение
А вот тут можно подробнее, почему одинаково (пусть это уже и оффтоп)?
Веронятно потому что в кэш (CacheLookup=Found) что-то кроме AccountNum положить надо? И потом как-то резолвить из него
Цитата:
Best practicies опять же, настаивают именно на варианте "укажите в запросе конкретные нужные вам поля
Best practices это же не религиозные догмы, и мы инженеры а не последователи культа. Это рекомендации, их нужно понимать, применять осознанно и проверять. Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных). С Azure SQL это мне кажется еще менее актуально, тут скорее латентность и geographic redundancy кроют пропускную способность как бык овцу

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

Последний раз редактировалось Vadik; 01.02.2019 в 10:34.
За это сообщение автора поблагодарили: skuull (5).
Старый 01.02.2019, 09:51   #24  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от Vadik Посмотреть сообщение
Я не сталкивался с ситуациями где такая оптимизация в моем коде что-то решала бы (по крайней мере там где нет массивных BLOB-ов хранящихся в базе данных).
Если у вас есть покрывающей индекс и вам нужны только поля из него, то указание списка полей избавить вас от второго обращения к кластерному индексу за всей строкой. Это не изменит мир, но точно будет быстрее. А зачем делать медленнее если можно быстрее?

Последний раз редактировалось skuull; 01.02.2019 в 09:53.
Старый 01.02.2019, 09:57   #25  
Stitch_MS is offline
Stitch_MS
Участник
Аватар для Stitch_MS
Соотечественники
 
287 / 279 (10) ++++++
Регистрация: 27.02.2006
Адрес: Дания
Ну вы даете. В #1 забыли firstonly. Так что ответ #2.
Старый 01.02.2019, 09:59   #26  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,426 / 1549 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Ну вы даете. В #1 забыли firstonly. Так что ответ #2.
Ну давайте firstfast добавим тогда, он же тоже +3 к скорости дает . Прекрасный пример слепого следования BP, или ну очень тонкий юмор
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 01.02.2019 в 10:15.
Старый 01.02.2019, 10:16   #27  
Raven Melancholic is offline
Raven Melancholic
Участник
Аватар для Raven Melancholic
Самостоятельные клиенты AX
Лучший по профессии 2015
 
1,778 / 952 (35) +++++++
Регистрация: 21.03.2005
Адрес: Москва-Петушки
Цитата:
Сообщение от Stitch_MS Посмотреть сообщение
Ну вы даете. В #1 забыли firstonly. Так что ответ #2.
Ну, MS SQL достаточно сообразительный товарищ и знает, что по уникальному индексу можно вернуть только 1 или 0 записей. Поэтому он и без подсказки не будет рассматривать варианты оптимальной выборки множества записей.
Старый 01.02.2019, 10:37   #28  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от Raven Melancholic Посмотреть сообщение
Ну, MS SQL достаточно сообразительный товарищ и знает, что по уникальному индексу можно вернуть только 1 или 0 записей. Поэтому он и без подсказки не будет рассматривать варианты оптимальной выборки множества записей.
Насколько я понимаю, при указании firstonly еще и AOS занимается оптимизацией всяких своих внутренних буферов и сетевых обменов, поскольку он знает что второй записи не будет.
За это сообщение автора поблагодарили: Logger (1).
Старый 01.02.2019, 10:41   #29  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Если у вас есть покрывающей индекс и вам нужны только поля из него, то указание списка полей избавить вас от второго обращения к кластерному индексу за всей строкой. Это не изменит мир, но точно будет быстрее. А зачем делать медленнее если можно быстрее?
Потому что указание списка полей может порождать очень интересные ошибки кодирования, потому что где-то ниже по коду обратились к полю, которое забыли прочитать. То есть - список полей полезно указывать только если:
1. Точно есть покрывающий индекс или есть не нужные нам BLOB поля.
2. Этот самый select выполняется в недрах какого-то очень критичного по времени участка (ну например если этот select выполняется 1M раз и из за структур данных мы не можем его в какой-то внешний while select добавить).
Во всех остальных случаях указание списка полей приводит к достаточно неощутимой оптимизации, но при этом повышает вероятность очень неприятных ошибок.
За это сообщение автора поблагодарили: Vadik (1), EVGL (3), ax_mct (5), AlGol (1).
Старый 01.02.2019, 10:44   #30  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,426 / 1549 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от skuull Посмотреть сообщение
Если у вас есть покрывающей индекс и вам нужны только поля из него, то указание списка полей избавить вас от второго обращения к кластерному индексу за всей строкой. Это не изменит мир, но точно будет быстрее. А зачем делать медленнее если можно быстрее?
Для тиражируемого продукта, особенно если Вы единственный owner этого кода, или для критичного по производительности кода - да, почему бы и нет (хотя и тут "точно быстрее" требует уточнения "насколько быстрее"). Для проектной доработки "по месту", которую после тебя другие люди править будут, и к каким еще полям они обратятся и какие еще методы на таблице вызовут, и стоит этого вся эта оптимизация - вопрос на миллион
__________________
-ТСЯ или -ТЬСЯ ?

Последний раз редактировалось Vadik; 01.02.2019 в 13:17.
Старый 01.02.2019, 11:01   #31  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от skuull Посмотреть сообщение
Если у вас есть покрывающей индекс и вам нужны только поля из него, то указание списка полей избавить вас от второго обращения к кластерному индексу за всей строкой. Это не изменит мир, но точно будет быстрее.
Почему это будет быстрее то? ну т.е. диск у нас размечен секторами в 64КБ к примеру, он в любом случае прочитает все
По сети тоже пакет передается..
Где выигрыш то в скорости?
Старый 01.02.2019, 11:06   #32  
trud is offline
trud
Участник
Лучший по профессии 2017
 
725 / 940 (33) +++++++
Регистрация: 07.06.2003
Записей в блоге: 1
Цитата:
Сообщение от Vadik Посмотреть сообщение
trud, в Вашем примере сделано все (малый объем данных, выборка по непокрывающему индексу, диалог в транзакции) чтобы найти хоть какой-то сценарий в котором update_recordset работает хуже. Как пища для размышлений - да, годно. Насколько в реальных условиях несколько конкурентных update_recordset, на реальных объемах данных, завернутых в правильную обработку deadlock-ов, будут быстрее или медленнее (хотя бы в T2) - вот это уже было бы гораздо интереснее. Как Вы считаете?
Пример упрощение того что было в реальной жизни. Создан по результатам анализа накладной по закупке с включенной корреспонденцией в 2012(тут была тема). Но с замечанием согласен, надо добавить именно реальный сценарий в D365. попробую поразношу накладные на досуге
Старый 01.02.2019, 11:30   #33  
Vadik is offline
Vadik
Модератор
Аватар для Vadik
Лучший по профессии 2017
Лучший по профессии 2015
 
3,426 / 1549 (58) ++++++++
Регистрация: 18.11.2002
Адрес: гражданин Москвы
Цитата:
Сообщение от trud Посмотреть сообщение
Почему это будет быстрее то? ну т.е. диск у нас размечен секторами в 64КБ к примеру, он в любом случае прочитает все
Потому что гладиолус Key lookup (clustered) , а данные и некластерный индекс в разных экстентах лежат
__________________
-ТСЯ или -ТЬСЯ ?
Старый 01.02.2019, 12:18   #34  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Потому что указание списка полей может порождать очень интересные ошибки кодирования
Любой код может содержать ошибки кодирования, так себе аргумент. Как не напиши, все равно умельцы все испортят и индексы ваши поломают и BLOB поля добавят и ваш код в цикл завернут и начнут крутить 1м раз, потом еще пальцам тыкать будут и говорить что он медленный. Так и до php не далеко.

Эта дискуссия имеет смысл только в случае, когда есть потребность сделать быстрее. Если мы пишем что-то что вызывается раз в году и обрабатывает 1 строку и так будет в обозримом будущем, то вообще все равно как оно написано. Но вот топикстартеру нет, он собирается вводить новые BP. А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.
Старый 01.02.2019, 12:38   #35  
EVGL is offline
EVGL
Moderator
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,792 / 2331 (85) +++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Много слов ни о чем. Солидаризуюсь с fed, только обращу внимание не на ошибки, а на расширяемость кода. Если вы не используете Query или SysDa, то добавить новое поле в середину метода невозможно.
За это сообщение автора поблагодарили: Vadik (1).
Старый 01.02.2019, 12:49   #36  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
А если вы пишете продукт, который будет обрабатывать большие объёмы, то с командой людей, которые не могут писать нормальный код вы далеко не уплывете. Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.
Вопрос в том, как нанять таких людей, за те деньги, которые клиенты готовы платить за проект.
Кроме того - я просто замечу, что большая часть твоих постов на форуме - это либо троллинг (неуспешный), либо - демагогия (тоже не особо удачная). Можешь, конечно, продолжать в том же духе, но похоже что более или менее активные участники уже все поняли...
Старый 01.02.2019, 13:08   #37  
ax_mct is offline
ax_mct
Участник
Аватар для ax_mct
 
2,330 / 884 (34) +++++++
Регистрация: 10.10.2005
Адрес: Westlands
Цитата:
Сообщение от fed Посмотреть сообщение
Потому что указание списка полей может порождать очень интересные ошибки кодирования, потому что где-то ниже по коду обратились к полю, которое забыли прочитать.
Цитата:
Сообщение от skuull Посмотреть сообщение
Любой код может содержать ошибки кодирования, так себе аргумент.
...
Нельзя жертвовать скоростью в угоду возможным идиотам, так привидеться писать методы по 500 строк, потому что они по-другому не поймут, им так удобней, чтобы все под рукой.
Тогда я бы добавил в Best Practices что список полей уместен только для локальной табличной переменной в небольшой функции. То есть когда этот список всегда перед глазами, и то в 50% сам спотыкаешься когда этот свой код позже расширяешь. То есть такая фишка никогда не должна быть глобальной.

Довольно непрактично оптимизировать код сразу. Это второй этап. Надежность и возможность дебага на первом этапе.
А то доходит до смешного когда такой оптимизированный код приходиться расчленять чтобы видеть в дебаге почему ничего нет в этом супер-пупер навороченном select со списком полей и join.
За это сообщение автора поблагодарили: AlGol (1).
Старый 01.02.2019, 13:12   #38  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Кроме того - я просто замечу, что большая часть твоих постов на форуме - это либо троллинг (неуспешный), либо - демагогия (тоже не особо удачная). Можешь, конечно, продолжать в том же духе, но похоже что более или менее активные участники уже все поняли...
Мы с вами на брудершафт не пили (С) Спасибо за замечание, также я ценю ваше желание высказываться за других людей, но давайте не будем переходить на личности? Оценка моих высказываний тоже не тема данной дискуссии и я вас о ней не просил. Если очень хочется, создайте новую тему в курилке и будем там выяснять где троллинг, а где экспертное мнение
Старый 01.02.2019, 13:25   #39  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,459 / 4662 (160) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от skuull Посмотреть сообщение
Мы с вами на брудершафт не пили (С)
Я начинал во времена FIDO и там принято было всех называть на "ты". Обращение на "Вы" считалось скрытым наездом. Так что прощу извинить мою старомодность - теперь буду обращаться только на "Вы". Однако все остальное в моем высказывании - остается в силе.

Последний раз редактировалось fed; 01.02.2019 в 13:58.
Старый 01.02.2019, 14:09   #40  
skuull is offline
skuull
Участник
Most Valuable Professional
Лучший по профессии 2014
 
616 / 629 (22) +++++++
Регистрация: 08.03.2013
Адрес: ХЗ
Цитата:
Сообщение от fed Посмотреть сообщение
Я начинал во времена FIDO и там принято было всех называть на "ты". Обращение на "Вы" считалось скрытым наездом. Так что прощу извинить мою старомодность - теперь буду обращаться только на "Вы". Однако все остальное в моем высказывании - остается в силе.
Спасибо, я вас их забирать не просил, высказывайтесь на здоровье, но в подходящей для этого теме.

Я согласен, что список полей может вызывать ошибки чаше чем выборка всей записи. Для этого есть "Error on Invalid Field access", активно рекомендуемый МС, но это тема отдельного топика. Есть аргументы в пользу того, что он может быть медленнее чем выборка всей записи?
За это сообщение автора поблагодарили: Vadik (1).
Теги
#покормитроля, как правильно, производительность

 

Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

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

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 15:54.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.