Element.Issues is very very slow

[Geert Bellekens]

Traversing the Element.Issues collection is very very slow.
(I think I reported that once before, but I can't seem to find the topic )
I spent a little time with SQL profiler to find out what exactly was happening.
The code I used was a simple

Code: [Select]

               foreach (EA.Issue issue in this.wrappedElement.Issues)
                {
                    this.issues.Add(issue);
                }Now when the this.wrappeElement.Issues get first initialized EA does following on the database:

Code: [Select]

Select 'problem=' + Problem + ';' + 'type=' + ProblemType + ';'  As Issue
from t_objectproblems where Object_ID=2146247310Then each time the enumerator goes to the next issue another command is issued to get the details of that specific issue.

Code: [Select]

Select * from t_objectproblems
where 'problem=' + Problem + ';' + 'type=' + ProblemType + ';' = 'problem=ACVPackage¶ Geert Bellekens¶ Element should have comments_(13/04/2010 11:37:46.82);type=Defect;'
and Object_ID=2146247310This is just ridiculous  
No other EA.Collection is managed that way!

If a developer on my team would pull one like that  

I'll report it as a bug.

Geert

[Geert Bellekens]

Received reply from Sparx:

Hello Geert,

Thank you for your report.

Although this collection is somewhat slow, it is not the only collection
to operate in this way and this behavior will not be changed in the
foreseeable future. Sorry we could not be of more assistance.

to which I replied:

As you can image I'm pretty disappointed by this decision.
Saying that the Element.Issues collection is "somewhat" slow is a serious understatement.
I ran into this issue while developing a model validation tool.
I basically visit all elements of package and for each element I visit its sub-elements, attributes, operations and relations.
For each of those elements/attributes/operations I run a number of validation tests to check whether they are valid in our methodology.
For each rule that is not valid I create an Issue on the element that is violating the rule.

I'm running my tests on a package with ~4000 elements and ~10.000 attributes.
In total there are about 17.000 issues in the package.

When I run my validator in a profiler I can see that it spends 68% of its time retrieving and looping the Issues.

The total runtime of my validator is now 45 minutes, but 30 minutes of those is spent just retrieving the issues (that is without saving them to the database)

Don't you think that is becoming a bit ridiculous?
Why can't you handle the issues similar to attributes and operations?

Regards

Geert

I hope they will reconsider

Geert

[Paolo F Cantoni]

Received reply from Sparx:

[size=18]...[/size]

I hope they will reconsider

Geert

So do I (as I intend to do something similar)...

What was the formal name of your bug report - so we can add our support?

Paolo

[Geert Bellekens]

Paolo,

The title was Element.Issues is very very slow
The reference number I got is 10045396

Geert

[Paolo F Cantoni]

Paolo,

The title was Element.Issues is very very slow
The reference number I got is 10045396

Geert

Formal support provided...

C'mon folks - let's all formally support Geert in this!  He's just the "point man" - we'll soon be in the same boat!

Paolo

[Geert Bellekens]

Thanks for your support Paolo.

I've been thinking about this, and the principle really seems wrong to me.
If I retrieve a collection, I expect everything to be in memory, so nothing can change to it, looping such a collection should be an in-memory operation.
The way it works now, is that is retrieves every issue from the database the moment you access in in the collection.
So if somebody would delete an issue between retrieving the collection and getting the actual issue from the collection that would result in an error (since that issue doesn't exist anymore)

I have never seen a collection that works in this twisted way; and probably with good reason.

I just wonder which other EA.Collections work this way, and which don't. I might need to review my code depending on the this difference.

Geert