Large project

[jozn]

I have a large project (mainly a lot of generated codes) and facing this error: dot: graph is too large for cairo-renderer bitmaps. Scaling by 0.235786 to fit it is useless for that main package, can this render large image without scaling it?

ps: tried with svg but dot failed.

[ondrajz]

Could you please share the command you are using?

Are you using -limit and -ignore option? Because by default ALL the calls inside program are analysed; that means also calls inside std packages.

I recommend using -limit with prefix of your project base path so only calls inside this are analysed and also -ignore to set path prefix/es (separate by comma) which are not important for you.

[jozn]

I tested with different combinations of limit ,some crashed, some worked, some scaled. finally i could generate svg and better resolution images (0.55 and .8).

one of the command that worked: go-callvis -focus models -group pkg -limit ms/sun/models ms/sun | dot -Tsvg -o models12.svg ms/sun/models is the big package.

for other smaller package it works very good. thanks for your time and library.

[ondrajz]

So did you end up with some useful result, or not?

Are there other packages inside ms/sun/models directory? Because -limit works as prefix so any package inside that folder will be included as well.

---

By the way, do you mind sharing the result? I am very curious about real world examples so I can see how it behaves. If you can't share I understand.

[jozn]

So did you end up with some useful result, or not?

Yes i did. Thanks your tool is good.

Are there other packages inside ms/sun/models directory? Because -limit works as prefix so any package inside that folder will be included as well.

No its the only one.

This is one :http://www.filedropper.com/base_13 this is mostly generated codes (orm like):http://www.filedropper.com/models11

[ondrajz]

Woah, the models one is quite large indeed. Even the base one is little harder to view.

However, there might be a nice solution for this. I can see that functions inside some package or type are all positioned on the same level, even though I don't see any reason they would need to be.

I'll play around with some output configurations to see if I could get rid of this constraint. It would make large packages like this much clearer.

Thank you for sharing!

[jozn]

I can see that functions inside some package or type are all positioned on the same level, even though I don't see any reason they would need to be.

They don't need to be, but by putting things in different package i will a have dependency cycle problem. all generated code goes to one file so no problem.

Most of what has been outputted are struct types that are internal to generated codes and are prefixed with "__" if the this tools has the ability to ignore types that match certain prefix or keywords that would be great.

[ondrajz]

I have noted what you suggested with adding option to ignore types and I will consider how to best implement this to provide better control over filtering the output.

---

However you misunderstood what I meant. I was not suggesting for you to move your code or anything. My point was only about improving the output of the go-callvis for such large call graph as you provided.

In the picture below I marked the areas with calls which are impossible to distinguish from each other. In situations like this there is little benefit from generating this without using deliberate limits and ignores. Maybe it could be improved by using -minlen which makes the output wider so there is more space for the edges, but I think it could be improved further with some better config of dot. I have to play around with some different configurations.