|
![]() |
#1 |
Moderator
|
Цитата:
Сообщение от raniel
![]() Помотрел это механизм внимательнее. Когда мы из формы "Настройка версии калькуляции издержек" запускаем расчёт по новой строке, то в процессе расчёта формируются списки узлов (BOMCalcItemTask/BOMCalcItemInventoryDimensionTask) для расчёта цен спецификации в классе BOMCalcJob_All. И как я понял, каждая спецификация рассчитывается один раз. Это хорошо.
В этом же механизме можно запустить не по всем расчёт, а задать конкретную номенклатуру...это фактический тоже самое, что вы предлагаете сделать. Проверив как работает это механизм, особого прироста в производительности я не заметил. |
|
![]() |
#2 |
Участник
|
Сделал всё как Вы описали. Разницы совершенно ни какой нет. Один плюс у данного метода что за это время он рассчитывает цены всех входящих в нашу номенклатуру спецификаций.
|
|
![]() |
#3 |
Moderator
|
А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...
|
|
![]() |
#4 |
Участник
|
Цитата:
Сообщение от fed
![]() А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...
|
|
![]() |
#5 |
Moderator
|
Для подсчета колчества хелперов, достаточно посмотреть сколько дополнительных заданий появилось в пакетной задаче после запуска.
Для того чтобы оценить объем пересчитываемой номенклатуры - достаточно посмотреть BomCALCItemTask сгруппированный по уровням (поле Level или BOMLevel) где-нибудь после того как начали работать задания, пересчитывающие нижний уровень вложености |
|
![]() |
#6 |
Участник
|
Цитата:
Сообщение от fed
![]() А сколько у тебя хелперов работает на пересчете ? И какое среднее число номенклатур по уровням вложенности ? Ну то есть - если у тебя вложенность 8 и каждый BOM состоит из 2 номенклатур, то на нижнем уровне будет 256 номенклатур для пересчета, на 7 уровне - 128 и тп. При этом реальный выигрыш будет вероятно только для 2-3 последних уровней и всего процентов на 30-40 для каждого. В то же время, если у тебя, скажем, вложенность 8 и среднее число компонент - 5, то на нижнем уровне будет порядка 350000 номенклатур и выигрыш будет уже прямопропорционален числу хелперов...
Цитата:
Сообщение от fed
![]() Для подсчета колчества хелперов, достаточно посмотреть сколько дополнительных заданий появилось в пакетной задаче после запуска.
Для того чтобы оценить объем пересчитываемой номенклатуры - достаточно посмотреть BomCALCItemTask сгруппированный по уровням (поле Level или BOMLevel) где-нибудь после того как начали работать задания, пересчитывающие нижний уровень вложенности Как я реализовал тот механизм который Вы мне посоветовали. В Классе BomCalcJob_All есть метод prepareTasksForSelectedItems. Там идёт создания списка всех спецификаций которые нужно сформировать. Там я сделал анализ, что если мы накладываем фильтр по спецификации/номенклатуре, то формируем список только того что в неё входит(Кстати Вы были правы, что если указать номенклатуру без доработки то считается только она и не разбивается на составляющее). В принципе всё работает, но скорость таже ![]() |
|