Using DocumentElement Call Very Very Slow

[Screwtape]

Hi,

I'm using a script to call DocumentElement a large number of times, since I can't create the level of complexity I need in a custom script fragment, since you only can generate a single level of data and you can't hide things with bookmarks in a custom fragment.

The script works fine - but it is incredibly slow. Having put lots of debugging in place, it would seem that there is a huge overhead every time you call DocumentElement, so while the script executes everything else really quickly, this takes multiple seconds per call, and seems to be getting slower, perhaps in line with my repository size increasing?

Does anyone else have this problem, or better still, a solution?

Thanks!

Screwtape.

[Geert Bellekens]

I keep repeating myself it seems.
I've made really complex document without the need to use the document generator API.

I haven't even needed the new script document fragment.
With virtual documents, and lots of small and simple templates and fragments (some SQL or script fragments) I've always been able to produce whatever crazy documents the client required.

If the virtual document tends to be complicated I write a little script that automates the creation of the virtual document.

More info and an example here: http://bellekens.com/2015/11/12/tutorial-generate-complex-documents-from-enterprise-architect-with-a-two-step-semi-automated-approach/

Geert

[Screwtape]

Thanks Geert!

Months later I reply... please don't think you're wasting your breath...

I have used a variation on your scripts to generate the general structure of the document, and that works great.

However, I have a script which takes a BPMN diagram and generates a "scenarios" style set of steps. It mostly works very well, but it is very slow when it comes to actually constructing the steps list.

Because in custom fragments you can a) only have a single dataset, and b) the hiding via bookmark doesn't work, I have to have several templates for each type of row, which I call once per table entry, which is inordinately slow.

I've stared using this script from within RTF DocumentFragments, which is great for small diagrams, but more than a handful of steps and they fall foul of the 60sec timeout on custom scripts.

I guess I could generate a virtual document down to the level of individual table entries, but I suspect that would also be extremely slow, as I'd have hundreds of virtual document entries, and even with a small handful, my document takes a long time to generate.

I guess that's what lunchtimes are for... :-)

[Geert Bellekens]

If you post the script code we can have a  look a possible improvements.
iterating elements in the EA API is deadly for performance, so now I mostly get the elements I need using an SQL query and work from there.

Geert