v15.2 – Time to get QuickLinker filter list?

[Paolo F Cantoni]

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

[Eve]

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.

[Paolo F Cantoni]

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

[Eve]

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.

[Paolo F Cantoni]

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

[qwerty]

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.

[Eve]

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).

[Paolo F Cantoni]

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?

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?

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.

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

[qwerty]

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.

[Eve]

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.

[Paolo F Cantoni]

I've done some (semi-formal) testing and the results (so far) bear out Eve's assertions.  For the metatypes and diagrams I used...

• The first drag between two new (not used before) metatypes took a while (5+ seconds)
• The subsequent drag (either between the same two items or two items of the same metatypes) on the same diagram was in minimal time
• Switching to another diagram with the same metatypes, the same drag was in minimal time
• Switching back to the original diagram with the same metatypes, the same drag was in minimal time

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

[qwerty]

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.

[Paolo F Cantoni]

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

[Eve]

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.

[Paolo F Cantoni]

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