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

[skuull]

Цитата:

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

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

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

[fed]

Цитата:

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

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

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

[skuull]

Цитата:

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

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

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

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

[fed]

Цитата:

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

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

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

[skuull]

Цитата:

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

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

Мы с вами на брудершафт не пили (С) Спасибо за замечание, также я ценю ваше желание высказываться за других людей, но давайте не будем переходить на личности? Оценка моих высказываний тоже не тема данной дискуссии и я вас о ней не просил. Если очень хочется, создайте новую тему в курилке и будем там выяснять где троллинг, а где экспертное мнение

[fed]

Цитата:

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

Мы с вами на брудершафт не пили (С)

Я начинал во времена FIDO и там принято было всех называть на "ты". Обращение на "Вы" считалось скрытым наездом. Так что прощу извинить мою старомодность - теперь буду обращаться только на "Вы". Однако все остальное в моем высказывании - остается в силе.

[skuull]

Цитата:

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

Я начинал во времена FIDO и там принято было всех называть на "ты". Обращение на "Вы" считалось скрытым наездом. Так что прощу извинить мою старомодность - теперь буду обращаться только на "Вы". Однако все остальное в моем высказывании - остается в силе.

Спасибо, я вас их забирать не просил, высказывайтесь на здоровье, но в подходящей для этого теме.

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

[ax_mct]

Цитата:

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

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

Цитата:

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

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

Тогда я бы добавил в Best Practices что список полей уместен только для локальной табличной переменной в небольшой функции. То есть когда этот список всегда перед глазами, и то в 50% сам спотыкаешься когда этот свой код позже расширяешь. То есть такая фишка никогда не должна быть глобальной.

Довольно непрактично оптимизировать код сразу. Это второй этап. Надежность и возможность дебага на первом этапе.
А то доходит до смешного когда такой оптимизированный код приходиться расчленять чтобы видеть в дебаге почему ничего нет в этом супер-пупер навороченном select со списком полей и join.

[Vadik]

Цитата:

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

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

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

[trud]

Цитата:

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

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

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

[Vadik]

Цитата:

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

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

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