Оver-engineering - "зачем так сложно?"

[belugin]

Цитата:

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

Что-то стало быстрее?

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них

[Logger]

Цитата:

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

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора

Да, это так и CIL хорош для этих целей. (Хотя в случае корреспонденции, надо бы все же алгоритм оптимизировать, так как для большого числа строк CIL тоже не поможет. Слишком быстро растет время с ростом числа строчек в документе )
Но к сожалению есть ряд минусов, которые сильно портят впечатление.

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему Помогите найти: Сравнение производительности различных операндов при конкатенации строк
операция += в CIL ведет себя по-тормозному по сравнению с p-code. И никуда тут не денешься. только если переписывать код через StringBuilder или TextBuffer что сильно ухудшает читаемость.

пп. 1-2 зануляют все плюсы CIL
Рука тянется за револьвером

[belugin]

Цитата:

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

1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть.
Почему бы не дать нам выбор ? Зачем гвоздями прибивать?

Ответ на этот вопрос я не знаю.

Цитата:

2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.

Как тогда реализовано Edit and Continue ?

Цитата:

3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему

Интересно. Тут вопрос за счет чего это и нельзя ли пофиксить помпилятор чтобы он для конкретного случая генерировал StringBuilder. Спасибо за ссылку

[Logger]

Цитата:

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

Интересно. Тут вопрос за счет чего это ...

Вероятно, причина в этом:
Помогите найти: Сравнение производительности различных операндов при конкатенации строк

[Logger]

Цитата:

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

Как тогда реализовано Edit and Continue ?

Интересно. Но если я не ошибаюсь, в аксапте такое не прокатывает. По ссылке речь об отладке в VS в специальном режиме.

[belugin]

Цитата:

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

Интересно. Но если я не ошибаюсь, в аксапте такое не прокатывает. По ссылке речь об отладке в VS в специальном режиме.

Есть галка HotSwapping, тут вопрос, насколько медленнее работа с ней чем без нее - я не тестил.

[fed]

Цитата:

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

Есть галка HotSwapping, тут вопрос, насколько медленнее работа с ней чем без нее - я не тестил.

Не знаю как в последних CU, но по крайней мере до CU9 включительно, она намертво ломала сводное планирование и ресурсное планирование производственных заказов. В общем - в production ее точно лучше не включать....

[belugin]

Цитата:

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

Не знаю как в последних CU, но по крайней мере до CU9 включительно, она намертво ломала сводное планирование и ресурсное планирование производственных заказов. В общем - в production ее точно лучше не включать....

Вообще, интересно, это свойство конерктной реализации или хотсваппинга в дотнете в вообще, как это делают в других продуктах на дотнете и нет ли проблем со стабильностью у хотсваппинга на оришинальной X++ машине.

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

[ax_mct]

Цитата:

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

ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.

Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них

Моя категоричность она для чистоты лечения

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое решение.

Но нам же неинтересен плоский T-SQL так как 3D OOП, не так ли? Вот оно и есть - программизм.

[mazzy]

Цитата:

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

Те же хранимые процедуры это стандартное и приемлимое решение.

Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь.

Цитата:

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

Моя категоричность она для чистоты лечения

не надо, пожалуйста.
открывайте балаган в курилке в новой ветке.

[belugin]

Цитата:

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

Моя категоричность она для чистоты лечения

Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.

Цитата:

Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое
решение.

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

[mazzy]

Цитата:

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

ax_mct, в отдельной ветке, пожалуйста.

[ax_mct]

Цитата:

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

Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.

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

Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX.

Речь не о лечении Аксапты, с ней все ясно на самом деле, а о лечении наших больных голов.
Очень вероятно что Аксапту похоронили не злобный и циничный Майкрософт, а романтики программирования с горящими глазами верящие в светлое будущее программизма.

Инструментарий для кодирования лучше/хуже, способ программирования лучше/хуже - это диагноз.
Аксапта это продукт для кого?
Я не ностальгирую по Аксапте, я сожалею о безумстве которое в головах.

[belugin]

Цитата:

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

Инструментарий для кодирования лучше/хуже, способ программирования лучше/хуже - это диагноз.

Вы же сами рассуждаете о том, что способ программирования худше или лучше