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

[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++ машине.

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

[fed]

Цитата:

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

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

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

Насколько я помню, это глубоко частный, спефицический случай, связанных с поведением внешнего оптимизатора (который в виде .net assembly поставляется, без исходных текстов). Но поскольку почти на всех внедрениях есть хоть какое-то призводство, приходится галочку везде отключать.
P.S. Официальное описание проблемы.