Why InitializeComponent() takes more time in Vb.net compared to vb6

[IT_Researcher]

Recently, we have met a problem in our product which is a winforms application, a large number of controls are added in the form. But it seemed a little slow when launching the application. When we used the profiler we found that InitializeComponent() is taking 47% of the total time. Profiling indicates that almost all of this CPU time is spent calling the various InitializeComponent methods of all the different UserControls. We want to reduce this time Please let me know if there is any way.
The application is a conversion from vb6 to vb.net and also uses com control and array controls .

We have come across https://www.infragistics.com/communi...een-open-delay
which suggest using NGEN if the project is referencing .NET 4 or higher, there is an issue in .NET that causes the dlls to be JITed slowly. But our application is not of .NET 4 or above.

[Shaggy Hiker]

I'm not sure there is any good way to speed up the creation of the controls, but depending on your situation, you might be able to improve the performance of the application. If the form with all the controls is your initial form, this won't work, but if it is any other form, then you pay the cost when you create the form, not when you show it. Therefore, if you can create the form well before you want to show it, then showing it will happen smoothly.

For example, I have a form that dynamically creates a large number of controls. It could take a noticeable amount of time to be created, especially since the number of controls is not well known right off. To improve the performance, I create the form with the most controls I will need, and do that before I need the form. By the time I'm ready to show the form, it has already been created, as have all the controls I could use. This is somewhat wasteful, as there are more controls than I am likely to be able to show, but the performance is good. In other words, I am sacrificing memory to improve performance.

[Niya]

I'm speculating here but I think what this really comes down to is best practices in VB.Net versus best practices in VB6. Instantiating controls at runtime in VB6 is pretty messy so it encourages a lot of VB6 programmers to create heavy forms with a lot of controls at design time and hide them until needed. However, in VB.Net it's pretty clean and easy to create new controls at run-time and wire up their event handlers so you should be creating lighter forms and instantiating new controls on an "as-needed" basis.

Doing a straight conversion of a VB6 program to VB.Net is almost always a very bad idea. The environments are fundamentally different. What works well in one environment, works poorly in the other. In .Net, it's better to do things "the .Net way".

[Shaggy Hiker]

I think that's a pretty good speculation, but would go even further. One of the nicer things in the design of .NET is that controls are just code. In VB6, creating controls was a bit odd, because the designer didn't handle control creation as 'just more VB6'. It was a bit arcane. In .NET, controls are just objects like any other object. InitializeComponents doesn't do anything you couldn't do yourself. In fact, I have a program written using a code generator that did all control initialization in a Region block in the form. That's how it had to be back before partial classes were introduced in 2005, yet that code still works fine in VS2022.

It's just code. It's .NET code like any other .NET code, and can be arranged and located in any fashion that is legal for .NET code. That wasn't happening in VB6, and there's a reason for that. Controls are a bit special. Creating something like a Listbox control in .NET is nothing all that special to anybody working in .NET, but under the hood, controls require quite a bit of rendering relative to most classes. What pixels to draw, where, and what colors, can be quite involved for something like a Listbox. To make such a control appear to be just a class like any other class, requires that quite a bit go on under the hood. That can have a cost. In Windows, every control is a window. I always felt that VB6 controls were a thinner layer on top of the underlying window than .NET controls. Making them more familiar incurred a cost.

On the other hand, I've never bothered looking to see whether or not that perception is based in reality. For my work, it doesn't matter.