Add count of FCDA used in ExtRefs, part of #958

[danyill]

I had a go at prototyping counting the number of references to an FCDA in project ExtRefs as suggested in #958.

It's by no means complete. However, it seems to ruin the plugin's performance by initially making it slow to load after clicking on the editor and then slow to update after doing a binding. It's so laggy I think it would be unacceptable to users.

I would appreciate a little guidance or a hint. How should I best approach this? Can this be made async?

[danyill]

I guess we could index all ExtRefs and then update the index as they are created or removed. Is that the best approach?

[danyill]

Hmmmm... incidentally on a large scd file I notice sticky behaviour with the existing implementation (quite apart from the counts).
Possibly performance could be improved by applying this indexing to the "Available to Subscribe" and "Subscribed".

Using this example file, it takes about 3 seconds between a click on the left-hand side and an update on the right-hand side.

IOP_2019_HV_v9_ed2.1.zip

[danyill]

I had a look at the performance in Chrome, and it seems like indexing is the way to go. A little wip pushed and now I must learn a little more about events between components. Another day 😉

[danyill]

I am now ready and would be grateful for a review.

This could be made even faster if we updated the count rather than re-indexing on each subscription action, but that seems excessive.

[danyill]

I have made some improvements, added some tests and rebased against main and would be grateful for a further review.

I found that I could not access this.doc even though AFAICT it is bound correctly and I can access other class instance properties and would appreciate some guidance there.

[dlabordus]

Hi Daniel,
Not fully the idea I had for the change to make the map uses smarter.

Check this patch how I would do it.
review.zip

But I think there is also something wrong with the counting. I used your file and the counter say 2, but there are no subscribed shown.

[dlabordus]

@danyill, I like the changes.

We only have one issue, I also did a big refactoring for the Subscriber - Logical Node Plugin (GOOSE/SMV).
So we will have several merge conflicts and also need to figure out how to make it work for both.

My proposal is to take your code in a new branch that includes the new plugin and make it work for both plugins (Later and Logical Node Binding). This way I will solve the big conflict I create with refactoring for the new plugin.

Do you find this a good idea?

[danyill]

Thank you for this patch and for looking at this 👍

But I think there is also something wrong with the counting. I used your file and the counter say 2, but there are no subscribed shown.

• In your example above there are two ExtRefs but I think they may be invalidated by the additional tests done for schema revision. We should probably do the same checks in the count as are done in showing the subscribed ExtRefs so these always match with what is shown. WDYT about extracting getExtRefElements and getSubscribedExtRefElements into the foundation? I pushed some commits showing this, although the call signature is perhaps messier than desirable.

• I shouldn't use identity(fcda) for indexing, because that is associated with the dataset, not the control block. I need to key it using both fcda and control block otherwise I get false counts if e.g. a dataset has been mapped to two control blocks (common for sampled values).

• I noticed a little bug in passing, srcPrefix had been misspelled in the attribute check for the schema. I corrected it (in 7721084).

I like the changes.

Oh hurrah, we are making progress. 😄

My proposal is to take your code in a new branch that includes the new plugin and make it work for both plugins (Later and Logical Node Binding). This way I will solve the big conflict I create with refactoring for the new plugin.

Do you find this a good idea?

Yes please, that would be great.