sequence diagram may generate a lot of duplicated items

[andy-yx-chen]

in one of my projects, I found the sequence diagram is not readable as it would generate a lot of duplicated items, I ended up need to do the dedup during the diagram generation such as this change, any idea or better fix?

[bkryza]

@andy-yx-chen Thanks for reporting this and debugging the code to fix it. I'm AFK this week, but I'll try to reproduce it and incorporate your fix next week...

[andy-yx-chen]

@andy-yx-chen Thanks for reporting this and debugging the code to fix it. I'm AFK this week, but I'll try to reproduce it and incorporate your fix next week...

Thanks for the timely reply, by the way, the diff I presented contains some changes needed for mac m3 pro, I build llvm project myself, don't know if we need to adjust the build scripts as well, but I think we should exclude building tests from release builds.

[bkryza]

@andy-yx-chen I've looked into your issue, and I'm not sure I understand it's intent. The only test case that behaves differently is t20052, where the calls to a() and b() methods from a nested lambda are skipped.

Can you write a small snippet of code that behaves differently between the current master branch and your changes?

[andy-yx-chen]

sorry, I am a bit busy recently, I will come back to you with a repro about the problem that I am solving, maybe I also need to take care of the nested lambda, for some reason, in at least two of our production code repo, without my fix, the sequence diagram that the tool generates creates a lot of duplications, such as a if block, or a function call (same function call or block) will be shown up hundreds of times, one of the massive example is before my fix, the svg file created by plantuml can result in 19MB, after the fix, it's just 30KB

[bkryza]

@andy-yx-chen Thanks, a piece of code reproducing the problem would be very helpful. In the meantime, I realized that I can easily add an option to "fold" repeating activities, i.e. if a function or method is called multiple times within the scope of a single sequence diagram, subsequent calls to it do not have to render all it's outgoing messages.

The option is called fold_repeated_activities and when set to true it will render each activity once, and any subsequent calls to that activity will only contain a note with a single character - * - indicating that it has been already rendered before. You can see that in action in this test case t20056.

This option is now available in master branch.

I'm not sure if this will improve your diagrams, but you can try, just add to your diagram config:

fold_repeated_activities: true

[andy-yx-chen]

@andy-yx-chen Thanks, a piece of code reproducing the problem would be very helpful. In the meantime, I realized that I can easily add an option to "fold" repeating activities, i.e. if a function or method is called multiple times within the scope of a single sequence diagram, subsequent calls to it do not have to render all it's outgoing messages.

The option is called fold_repeated_activities and when set to true it will render each activity once, and any subsequent calls to that activity will only contain a note with a single character - * - indicating that it has been already rendered before. You can see that in action in this test case t20056.

This option is now available in master branch.

I'm not sure if this will improve your diagrams, but you can try, just add to your diagram config:

fold_repeated_activities: true

I will give it a try, but I think this may not completely help, my case is in some cases, the following code

void B();
void A() {
  if (some-cond) {
    B();
 }
}

would generate diagram something like
A
{
alt (some-cond) {
-> B;
}
alt (some-cond) {
-> B;
}
alt (some-cond) {
-> B;
}
alt (some-cond) {
-> B;
}
...
}

even I tried to use json output, I still can see the same pattern, I need some more time to figure out how to repro, as I cannot share our proprietary code here.