Sparx Systems Forum

Enterprise Architect => Automation Interface, Add-Ins and Tools => Topic started by: Paolo F Cantoni on July 14, 2021, 09:03:12 am

Title: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 14, 2021, 09:03:12 am
Some time back (perhaps as much as a couple of years ago) we were told by (IIRC) Sparxian Eve, that there was, effectively, no maximum value for the number of QuickLinker entries that could be supported.  It certainly seemed to be the case, we were generating a large number of entries (~30K, in the OLD QuickLinker segment format).

As we've increased the number of metatypes and relationships we are defining between them (and also some of the derivations may be multiple levels deep) we are finding the (at least initial) QuickLinker time to decide which options to provide is getting very long (sometimes close to 10 secs).  It also seems to have come about in a non-monotonic way (that is, it suddenly got slower).

We concede that we may be at the "bleeding edge" of such usage, but it would be interesting to try to determine why this is the case.  With the new model-based environment, is it possible there might a "knee" in the graph that would explain the slow-down?  We find that if we are modelling between more than one diagram at a time, as we switch from diagram to diagram, the amount of time required seems to "reset" each time we switch diagrams (as though it was a new diagram).

Anyone else seen anything similar?  The current slowness will potentially impede our end-user experience.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 14, 2021, 10:36:42 am
I'll start by saying there's no explicit limit. I'm confident you'll hit limits with an impractical UI long before you hit limitations relating to datatypes or memory.

EA is building a complete list of all available triples (start, connector, end) with the first use. I suspect without proof that it's this collection that's causing your problem. That is then used to build the relevant quicklinker entries based on the specified start/end types being used and sorting those generated records. That's the other place that will cause an accelerating slowdown with larger lists.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 14, 2021, 10:55:55 am
I'll start by saying there's no explicit limit. I'm confident you'll hit limits with an impractical UI long before you hit limitations relating to datatypes or memory.

EA is building a complete list of all available triples (start, connector, end) with the first use. I suspect without proof that it's this collection that's causing your problem. That is then used to build the relevant QuickLinker entries based on the specified start/end types being used and sorting those generated records. That's the other place that will cause an accelerating slowdown with larger lists.
Thanks, Eve,
this is what I suspected.  However, to help me understand the process, can you confirm (or deny  ;))...
1) That the list is created ONCE per session.  Conceptually, "available triples" is a fixed quantity (given the set of available MDGs)
2) That a specific subset (start, end) is cached for re-use after first use by the user?  Again, the subset is a fixed filter (is it not) on the set of triples and so can be calculated once.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 14, 2021, 02:07:18 pm
I'll give you a qualified confirmation for both of those points.

Any change to the technology list will invalidate both collections. That includes updating a technology and switching or reloading a model.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 14, 2021, 02:59:09 pm
I'll give you a qualified confirmation for both of those points.

Any change to the technology list will invalidate both collections. That includes updating a technology and switching or reloading a model.
Understood (about technology - it was a "given")

Is that the qualification to the confirmation?  If not, what else is the qualification?

Some further questions...
If I have already dragged from "A" (metatype X) to "B" (metatype Y) (and waited, say 6 secs) for the list to be generated; if I now drag from "A" to "C" (also metatype Y), on the same diagram, should the list now be "instantaneous"? If not, why not?
If I now switch diagrams (with the same toolbox) and drag from "C" (metatype X) to "D" (metatype Y), will that also be the same length of time as "A" to "C" on the first diagram?  If not, why not? 

(just seeking clarification)

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 14, 2021, 06:09:59 pm
I never been in any reach of your numbers (because dealing with that table just was insane from my POV). Anyhow, implementing a search through that might well be done good and bad. The simple (and I would guess Sparxian) way would be some linear search. Or maybe it's a tree search gone into the bushes (haha). I bet that it's not done the most sufficient way, namely a hash. All speculation, though.

q.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 15, 2021, 11:17:42 am
Yes, that was the qualification. It may be a "given" to me, but I'd rather be cautious about my assumptions.

If I have already dragged from "A" (metatype X) to "B" (metatype Y) (and waited, say 6 secs) for the list to be generated; if I now drag from "A" to "C" (also metatype Y), on the same diagram, should the list now be "instantaneous"? If not, why not?
I would expect a minimal time. It should be quicker than an old style quicklinker table.

If I now switch diagrams (with the same toolbox) and drag from "C" (metatype X) to "D" (metatype Y), will that also be the same length of time as "A" to "C" on the first diagram?  If not, why not? 
It should be the same.

I never been in any reach of your numbers (because dealing with that table just was insane from my POV).
Exactly why I'd recommend using metaconstraints. I'm aware of a number of homebrew solutions to generate the tables before we implemented metaconstraints.

I never been in any reach of your numbers (because dealing with that table just was insane from my POV). Anyhow, implementing a search through that might well be done good and bad. The simple (and I would guess Sparxian) way would be some linear search. Or maybe it's a tree search gone into the bushes (haha). I bet that it's not done the most sufficient way, namely a hash. All speculation, though.
Fun fact. It's not always obvious which one you're using. In C++, std::map is a balanced binary tree. O(Log(n)) for insert or query. By contrast MFC CMap classes use a hash table. You would think that they would be O(1), but the default size of the table is only 11 records and collisions are handled with a linked list. Actual performance for a query if you don't specify a size ends up being O(n).
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 15, 2021, 12:08:27 pm
Thanks for the clarifications, they help a lot!
Yes, that was the qualification. It may be a "given" to me, but I'd rather be cautious about my assumptions.

If I have already dragged from "A" (metatype X) to "B" (metatype Y) (and waited, say 6 secs) for the list to be generated; if I now drag from "A" to "C" (also metatype Y), on the same diagram, should the list now be "instantaneous"? If not, why not?
I would expect a minimal time. It should be quicker than an old-style QuickLinker table.
By minimal you mean much less than the original 6 secs, yes?
Quote
If I now switch diagrams (with the same toolbox) and drag from "C" (metatype X) to "D" (metatype Y), will that also be the same length of time as "A" to "C" on the first diagram?  If not, why not? 
It should be the same.
That is, the minimal time, yes?
Quote
I have never been in any reach of your numbers (because dealing with that table just was insane from my POV).
Exactly why I'd recommend using metaconstraints. I'm aware of a number of homebrew solutions to generate the tables before we implemented metaconstraints.
Yes, in our case they "worked", but they were difficult to maintain and generation was a pain.  The new mechanisms are much easier to maintain.  More importantly, they allow structured metamodelling to create the modelling universe that we (as Gods) create.
Quote
I have never been in any reach of your numbers (because dealing with that table just was insane from my POV). Anyhow, implementing a search through that might well be done good and bad. The simple (and I would guess Sparxian) way would be some linear search. Or maybe it's a tree search gone into the bushes (haha). I bet that it's not done the most sufficient way, namely a hash. All speculation, though.
Fun fact. It's not always obvious which one you're using. In C++, std::map is a balanced binary tree. O(Log(n)) for insert or query. By contrast, MFC CMap classes use a hash table. You would think that they would be O(1), but the default size of the table is only 11 records and collisions are handled with a linked list. Actual performance for a query if you don't specify a size ends up being O(n).
So, you don't create a default table but calculate the actual required size and create that to restore the speed?

I think you'll agree that getting this part of the UI to work as fast as possible is (verging on) critical.

So, I'll try some testing when I get some free time and get back.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 15, 2021, 07:49:54 pm
Fun fact. It's not always obvious which one you're using. In C++, std::map is a balanced binary tree. O(Log(n)) for insert or query. By contrast MFC CMap classes use a hash table. You would think that they would be O(1), but the default size of the table is only 11 records and collisions are handled with a linked list. Actual performance for a query if you don't specify a size ends up being O(n).
You should rather be working in the development than on the support I would guess...

Of course i never have seen any of EA's code (decompiled code does not really give you an idea in that scale). So my (damning) judgements rely only on the UI experience and what can be found as obvious (bad) in the database. Still, there's more good than bad. But I loathe those stains which could probably be removed or diminished with little effort.

q.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 16, 2021, 09:37:27 am
You should rather be working in the development than on the support I would guess...
My primary role is development. I'm here because I want the raw feedback that I can incorporate where possible.
Title: Re: v15.2 Time to get QuickLinker filter list? Some Tests
Post by: Paolo F Cantoni on July 16, 2021, 09:59:05 am
I've done some (semi-formal) testing and the results (so far) bear out Eve's assertions.  For the metatypes and diagrams I used...
This test was limited to only these two specific metatypes.

However, this seems to concur with Eve's assertions, yes?

I'll do some more testing and report back.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 16, 2021, 06:49:48 pm
My primary role is development. I'm here because I want the raw feedback that I can incorporate where possible.
Good to hear. When things got started there was a lifely interchange between users and developement (those times before the war). But I guess that procedures are now strict to keep the outsourced devs running - and the marketing happy :-/

q.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 19, 2021, 10:21:43 am
Hi Eve,
a quick question on the process.  I first noticed the significant initial delay because we are currently updating our MDG and round-tripping the repository with the MDG definition with the testing repository (which in this case happens to be the same one).  So we were restarting EA frequently.  Is the initial delay a once only "hit" (i.e. setting up the 40K+ relationship definitions)? Or is there an additional overhead for each origin-destination pair of metatypes?

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 19, 2021, 11:21:52 am
The biggest hit is the first use of the quicklinker.

It used to load the complete quicklinker list at that time, but it now only loads the necessary parts of the quicklinker list. That means there will be additional hits the first time any particular metatype is used. That time hasn't been significant for the technologies that are internal to EA, but there is a possibility for it to take some time.

Some useful times to measure:

1. Show 'Link Rules' for a strict perspective for fresh EA. (Time to expand all possible links + time to fill the dialog)
2. Show 'Link Rules' for a strict perspective a second time. (Time to fill the dialog)
3. Use quicklinker from a second metatype (or after showing link rules) to empty space in a fresh EA. (Time to build quicklinker + time to display quicklinker)
4. Repeat quicklinker from that metatype to empty space in fresh EA. (Time to display quicklinker)

That should give you an idea of where the time is being taken up. Obviously 3 & 4 will vary between different source elements, if you have one that you expect to be larger use that to give yourself an upper bound.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 19, 2021, 11:32:25 am
Thanks, Eve,

Most useful!  At present, we aren't using perspective (AFAIK) - other than the Claytons' one (the perspective you have when you don't have a perspective ;) ).
From what you are saying, it would seem that the effective use of well-specified perspectives will cut down the amount of subset selection required in the process.  Have I understood that correctly?

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Eve on July 19, 2021, 01:54:23 pm
No, I think I was unclear. I don't think the perspective is going to help you in this case. But I can use the perspective configuration dialog to help work out where the time is going.

To open the dialog I'm talking about:

The purpose of this dialog is to change the connections I can make, at the level of the triple I mentioned earlier. It also happens to be a great way to visualize the rules your technology allows. I've personally found it much more useful for that purpose than what it's actually for. Although interesting, none of that is why I'm mentioning it now. It's filled from the same list as the quicklinker, which means we can separate the different components of the time to work out where your problem is.

1-2 gives you the time taken to calculate all possible combinations for each connector.
3-4 gives you the time taken to build the quicklinker options. For most users they will also see 1-2 included in that first time. They will get closer to this figure when they use the quicklinker from a second type.

Generally speaking 4 needs to be as short as possible. There's a tradeoff between load on demand for 3 and load up front. As I said, the initial behavior was load up front. I think it was released like that, but once more technologies started using metaconstraints instead of the table we found that to get acceptable performance it needed to be load on demand.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 19, 2021, 04:54:43 pm
Thanks again for that, Eve!
This is, in my view, super cool!  8) 8)  I agree that using it to visualise the rules is a great use case!  I'm going to use it for that!
With your clarification, do I now understand correctly that I can have a number of perspectives (for the present, solely for this purpose) to confirm that the metamodel/MDG we're creating generates the correct set of rules for the particular perspective case?

I'm envisaging one for Power BI management, another for DB management, a third for ETL flow management etc. (you get the idea).  Or have I got it wrong again?  I haven't tried your instructions yet, I'm tasked with something else; but if I've got it right, I'll be taking a closer look soon!

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 19, 2021, 07:09:20 pm
Just a few marginal notes from me. I'm only starting to use these constraints. While the old csv format was just no way to go (trying to hammer a multi-dimensional structure into a flat format) the new approach also has its drawbacks. It's getting crowded quite fast. So it's hard to read what may be related and what not. I'm currently thinking of externalizing this into some data structure (be it JSON or whatever) in order to make it maintainable and then make some sort of bulk import. So although the new approach look much better it's still far from being "sliced bread". My own slices still do not look that delicious too right now :-/

q.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 19, 2021, 09:26:29 pm
Just a few marginal notes from me. I'm only starting to use these constraints. While the old csv format was just no way to go (trying to hammer a multi-dimensional structure into a flat format) the new approach also has its drawbacks. It's getting crowded quite fast. So it's hard to read what may be related and what not. I'm currently thinking of externalizing this into some data structure (be it JSON or whatever) in order to make it maintainable and then make some sort of bulk import. So although the new approach looks much better it's still far from being "sliced bread". My own slices still do not look that delicious too right now :-/

q.
Ah, yes.  Reading your post, I realise we're in a uniquely fortunate position with our Sparx setup.  As you know, we make extensive use of our diagrammer Add-In which creates "Neighborhood" diagrams.  Consequently, we can get a simplified view of all the relevant relationships and related items to the stereotype or metatype etc.

We can therefore create and manage VERY complex metamodels.  For example,
(https://imgur.com/800i3pw.jpg)
(NOTE: This is a simplified version of the Neighborhood diagram for the purposes of this discussion)
You can see the central stereotype PBIRprt (Power BI Report) and what other components it extends or inherits from.  This is manageable on a per-item basis.  One REALLY NICE feature of this diagram is the ability to simply create similar stereotypes.  We just select a (central) item that has the required characteristics and copy it using [Ctrl+Shift+V].  A quick rename and any customisations required for the new stereotype and we have a consistent, new item!  The new item then gets its own Neighborhood diagram.

Works a treat! (as it has for over a decade!).

All we need is for the inheritance to work properly over multiple levels of inheritance and (I believe) we'll be sweet!

As I said, we're very fortunate to have solved another enterprise-level modelling problem.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 19, 2021, 10:10:37 pm
Yes, I know that :-) I try to push peope doing that manually. Policies at my customer do not allow the use of add-ins (well, if he decides that running with weights on your feet will make us faster and he's still paying by time I do't care). I'm just digging out what in reality has been modeled (by going throug diagrams and list the used elements and connectors). It's not bottom up but mere digging out of the grave. Anyhow, I will have to dive into that and see what I can make of it.

q.

P.S. Seeing multiple inheritance in your metamodel makes me shiver. I still think that this is an evil concept. Maybe just me thinking that way.
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Paolo F Cantoni on July 19, 2021, 10:50:02 pm
[SNIP]

P.S. Seeing multiple inheritance in your metamodel makes me shiver. I still think that this is an evil concept. Maybe just me thinking that way.
Having read and absorbed Bertrand Meyer's Object-Oriented Software Construction, multiple inheritance doesn't worry me.

By using separation of concerns, multiple inheritance works very well and is another form of complexity management.  It's not trivial, but it definitely isn't rocket science, in this case.

We use it mainly for propagating decorations, shapes, property tags and USDPs in a structured and controlled fashion.

You can always simulate the Neighborhoord diagramming with a script (if that's allowed) or manually.

Paolo
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: Geert Bellekens on July 19, 2021, 11:34:51 pm
I'm just digging out what in reality has been modeled (by going throug diagrams and list the used elements and connectors). It's not bottom up but mere digging out of the grave. Anyhow, I will have to dive into that and see what I can make of it.
Ian developed an add-in especially to reverse engineer meta-models from model.

See http://www.abilityengineering.co.uk/index.php/tools/model-expert (http://www.abilityengineering.co.uk/index.php/tools/model-expert)

Might be helpful

Geert
Title: Re: v15.2 Time to get QuickLinker filter list?
Post by: qwerty on July 20, 2021, 12:43:42 am
See http://www.abilityengineering.co.uk/index.php/tools/model-expert (http://www.abilityengineering.co.uk/index.php/tools/model-expert)

Might be helpful

Geert
Brings me to a page not found 404 when clicking the model expert icon.

q.