|
![]() |
#1 |
Участник
|
ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.
Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них ![]() |
|
|
За это сообщение автора поблагодарили: Vadik (1), Logger (3), mazzy (2). |
![]() |
#2 |
Участник
|
Цитата:
![]() Но к сожалению есть ряд минусов, которые сильно портят впечатление. 1. Вот зачем было принудительно заставлять делать обработки только в CIL для пакетов и вебсервисов ? Есть ли какие-то технические ограничения ? Для пакетов так точно не должно быть. Почему бы не дать нам выбор ? Зачем гвоздями прибивать? 2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять. 3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему Помогите найти: Сравнение производительности различных операндов при конкатенации строк операция += в CIL ведет себя по-тормозному по сравнению с p-code. И никуда тут не денешься. только если переписывать код через StringBuilder или TextBuffer что сильно ухудшает читаемость. пп. 1-2 зануляют все плюсы CIL ![]() Рука тянется за револьвером ![]() |
|
![]() |
#3 |
Участник
|
Цитата:
Цитата:
2. CIL - очень негибкий инструмент. Он не позволяет накатывать по живой. Т.е. накатить то можно, но изменения не подхватываются. и это очень плохо. Жизнь требует чтобы можно было по живой код менять.
Цитата:
3. В некоторых случаях CIL может проигрывать старому p-code. Например, при интенсивной работе со строками. см. тему
|
|
![]() |
#4 |
Участник
|
Вероятно, причина в этом:
Помогите найти: Сравнение производительности различных операндов при конкатенации строк |
|
![]() |
#5 |
Участник
|
Цитата:
Сообщение от belugin
![]() Как тогда реализовано Edit and Continue ?
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#6 |
Участник
|
Цитата:
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
![]() |
#7 |
Moderator
|
Цитата:
Сообщение от belugin
![]() Есть галка HotSwapping, тут вопрос, насколько медленнее работа с ней чем без нее - я не тестил.
|
|
|
За это сообщение автора поблагодарили: mazzy (2), belugin (2), Logger (3). |
![]() |
#8 |
Участник
|
Цитата:
(Как не смутно помнится, надо было очень аккуратно перекомпилировать наследников, если как-то не до конца это сделаешь, то будут странные ошибки или тихо данные возьмутся из другого поля) |
|
![]() |
#9 |
Banned
|
Цитата:
Сообщение от belugin
![]() ДА. Разноски больших журналов СУЩЕСТВЕННО быстрее именно когда идут в CIL - за счет другого сборжика мусора особенно если включена корреспонденция. Алгоритмические проблемы не решаются просто добавлением оборудования. Там кажется был o(n2) или типа того.
Интересно, что вы пишете очень категоричным тоном, не зная таких делалей но спрашивая о них ![]() ![]() Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое решение. Но нам же неинтересен плоский T-SQL так как 3D OOП, не так ли? Вот оно и есть - программизм. |
|
![]() |
#10 |
Участник
|
Ритейл в акс7 построен на хранимых процедурах.
Не приведи господь. не надо, пожалуйста. открывайте балаган в курилке в новой ветке. |
|
![]() |
#11 |
Участник
|
Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.
Цитата:
Неужели инструментарий 3.0 не позволил бы программисту решить проблему разноски больших журналов? Те же хранимые процедуры это стандартное и приемлимое
решение. Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX. |
|
![]() |
#12 |
Участник
|
ax_mct, в отдельной ветке, пожалуйста.
|
|
![]() |
#13 |
Banned
|
Цитата:
Сообщение от belugin
![]() Вы думаете, что лечение происходит в AxForum? Я бы посоветовал нести боль в Яммер - там гораздо больше шансов быть услышанным принимающими решение.
Мне кажется инструментарий, который не заставляет прикладного программиста переписывать код для достижения того же быстродействия лучше в этом аспекте чем тот, который заставляет. Перечислите, пожалуйста достоинства и недостатки использования TSQL для обработки данных в AX. Очень вероятно что Аксапту похоронили не злобный и циничный Майкрософт, а романтики программирования с горящими глазами верящие в светлое будущее программизма. Инструментарий для кодирования лучше/хуже, способ программирования лучше/хуже - это диагноз. Аксапта это продукт для кого? Я не ностальгирую по Аксапте, я сожалею о безумстве которое в головах. |
|
|
За это сообщение автора поблагодарили: mazzy (2), Pustik (5). |
![]() |
#14 |
Участник
|
|
|
Теги |
sysoperation framework |
|
|