EA response is super slow in V13!?

[PeterHeintz]

I have be model were now even elementary actions like selection of a package in project browser or selecting an element on a diagram takes round about a minute to be finished.

I exported and imported (xml) the stuff in an new model (eap) to find out if I get rid of the problem but it is still there.
I also switched of all add-ins and non Sparx MDG’s. -> Problem still there.

Then I started to delete step by step packages in the hope to isolate something that causes the problem.
By doing so I came in an area of SysML blocks with a considerable amount of ports where each time I deleted something the EA response got a little bit faster.

These performance issues I see in V13:1304 and 1309, but I do not have in V12:1215
Anyone knowing something about that? Any idea?

[qwerty]

You best get in touch with Sparx' support.

q.

[PeterHeintz]

After some days this problem disappeared somehow. Maybe my IT used my PC resources for something some days.

[PeterHeintz]

I have this problem now again.

What I have observed so far:
Compacting the eap file solves the problem.
Checking out a fragment (even having few elements) from SVN make working almost impossible (super slow)
Compaction the eap file again solves the problem

In other words: each time I check out something from SVN I have to compact the eap file before I am able to work.
Any idea?

[qwerty]

I'd look into Mickeysoft Access fora. Any VC operation leads to massive deletions/creations of records. I could imagine that EAP files are not really prepared best for such kind of operations. Just a guess, though.

q.

[Helmut Ortmann]

Hi Peter,

the projects I worked for:
- EA with *.eap and Version Control ==> lot of problems, I have almost never experienced some benefits from Version Control
- EA with Database, no Version Control ==> runs smoothly

Today I look carefully into the processes to evaluate if Version Control is really needed and not a rarely needed functionality.

In most cases, baselines or simply write/export (not read) to Version Control will do the job. No locking, just writing. An Integrator who was also responsible for integrating the model told me that there are seldom merge conflicts and if they have solved them fast.

Processes like SPICE are talking a lot of the benefits of Version Control. It's a thing we have to use without thinking about. In praxis, you should look into the details and ask:
- What are the real benefits?
- What are the issues?
- Can I mitigate the issues?

Kind regards,

Helmut

[PeterHeintz]

Hello Helmut,
Thank you for your reply!

The way we use EA depends much on the nature of what is modeled and which users are intended to change what. In most projects we only create some snap shorts (SQL->eap) and put those to version control (more or less just to baseline the model stuff with other artifacts outside EA existing in subversion already.

However in some special cases, putting packages under version control works (worked) very well for us.

The project causing the problem worked very well for years, but now I need this Compacting workaround each time I do the checkout. The eap file is not such big (15MB after compact). After checking out an unchanged fragment, the eap size increases to 16.5 MB, what should also not cause a performance problem to EA.

Now I tried to reproduce the problem without packages connected to SVN and a pure package import causes the same problem. So I assume it is not a Subversion issue at all.

[Helmut Ortmann]

Hello Peter,

looks peculiar!

May be there is something damaged inside *.eap. I would try:
- Consistency check + repair
- Project transfer to an empty *.eap file
- Contact SPARX

Kind regards,

Helmut

[PeterHeintz]

I tried all 3 suggestions already.

When I send the EA-File to Sparx last time, they could not reproduce.

My next steps are to copy the stuff to my personal equipment to see if I can reproduce it outside my company as well and if so, to contact Sparx again.

[Glassboy]

What I'd suggest is you run a chkdsk and bleachbit over the machine and then try the problematic eap again.  The kind of mysterious slow down you discribe is normally related to some issue with the slowest part of the machine, i.e. the mechanical hard drive.

[PeterHeintz]

Now I tried to reproduce the problem on my private machine but I was not able to.
Next I will try to reproduce to problem on another office machine on my way to find what is behind the strange problem.

[PeterHeintz]

Trying to reproduce the problem on another machine of my company shows that my performance problem is on my personal company machine only.

[Glassboy]

Trying to reproduce the problem on another machine of my company shows that my performance problem is on my personal company machine only.

Then run bleachbit and clear out all the cruft on your file system and then run a chkdsk and fix any cross linked files.  It's likely to be the file geometry affecting paging from memory. 

[PeterHeintz]

Chkdsk and bleachbit did not help either.
Now I contacted my IT, maybe with those I can isolate the root cause if this strange thing.

[qwerty]

Sometimes it's easier to just get a new machine...

q.