Performance regression when loading an inherited form that requires scaling if this form contains a number of controls whose AutoSize property is set to True

We have found, that dxLayoutcontrol with complex form

layouts are slow to load (10-15 seconds), if we use form inheritance. Even RAD
Studio XE4 loads this form much slower, than other forms

My PC is an i5, with 8GB RAM, 256GB SSD, so, not the
hardware is slow.
In our tests, the constructor of the form runs
quickly, after that, the Loaded event is started instantly, but after the
Loaded event is finished, there is about 10 second delay, and after that, the
FormCreate event is called. Nothing from our code is run.
If the same layout, and all the other components are
put in a layout control, which isn’t inherited, it speeds up (1, max. 2
seconds to load the form. Even, if that layoutcontrol is on that interited
form.
Please, try this out.
In the attached sample, there are 3 forms.
-
the msz310_3a form is not inherited, and works fine.

-
msz310_3 is, where all the problems started. This is a
copy of one of our forms, what we use in our application. It is nearly useless.
For me, it is 10-15 seconds to load, but, with less powerful machine, it can
took minutes to load…
-
msz310_3b is a mixed one. It is inherited as the
msz310 (more precisely a Save as copy of the msz310_3), but I do not use the
inherited layoutcontrol (called pnl_form), and I dropped a new one into the
form, and dragged everything from the old layout to the new. It works fine,
loading speed is the same as the non-inherited form. When I drag the items back
to the inherited layout, it slows down again. Drag it to the new, and speed
comes back. You can try it on the msz310_3b form.

We tired to investigate, what happens. We used AQTime,
to check the procedure calls, and found something very strange. The results are
int he zip file, msz310-3-aq.txt and msz310-3a-aq.txt It shows method names,
call times and hit counts. The msz310_3a shows, that the most used method is
TcxControl::Notification, 662 thousand times, and 5 hundreds of a second.
TdxCustomLayoutItem::GetLayoutLookAndFeel was called half a million
times, 1 hundreds of a second. That’s good. The problem is in the
msz310-3-aq.txt file, which is the result of the original inherited form.
TdxCustomLayoutItem::GetLayoutLookAndFeel was called 50 million times, for more
than 2 seconds. TdxCustomLayoutItem::IsAvailable was the next, 47million times,
2 and a half seconds, and so on. Even the TdxLayoutGroup::GetIsRoot was 1 and a
half second, with nearly 40million times called. I don’t know what is the
problem, but somewhere something seems to be a nearly infinite loop. Strange
thing, but I started to build the msz310 screen from scratch, using the inherited
form structure. And until some point, it was fast. I used the root group tabbed
(as in the other forms), but the ther components were not groupped, but only a
vertical flow. But after some level of complexity (I don’t know where it was),
when I started to build up the previuos grouping structure, it slowed down
again.
I report this problem to the Devexpress 2013.2.3 version, but this problem exists since 2013.1.3 Currently we are using 2013.1.2, because that version works much faster in the layouts, due to the mentioned problems.