I have a winforms test application I have created that consists of one form that contains 3 UltraLabels, 1 UltraTextEditor, 1 UltraComboEditor and 2 UltraButtons. After creating the form, dragging the components mentioned above onto the form and building, I tried starting the app (there is no other code in the constructor). The form popped up in about .5 of a second. Then I created a .isl file for app styling saved the file and loaded the file using the following code:
Infragistics.Win.AppStyling.StyleManager.Load("TestStyleSet.isl", False)
The startup time went from .5 of a second to 2 seconds. So I did another test to see if it was just AppStyling that was the culprit and created an empty StyleSet and it still took 2 seconds to start this simple app. So then I decided I would not use app styling but rather style the controls I had put on the form individually. I proceeded to set the UltraTextEditor's DisplayStyle as Office2007 with this line of code in the constructor:
UltraTextEditor1.DisplayStyle = Infragistics.Win.EmbeddableElementDisplayStyle.Office2007
and tried starting the app again. The app took 1.6 seconds to start this time. I then removed the above line of code from the constructor (no code is in the constructor now) and I was back to .5 of a second for startup time.
Is there a reason using appStyling or setting the DisplayStyle of an UltraTextEditor should affect the startup time of an application so significantly? Is there a workaround for either of these scenarios?
Thanks,
Daren
Hi,
Let me know if you have tested Mike's suggestion or if you have further questions.
Regards,
Stefaniya
Hi Daren,
Yeah, it must be the case the using the Office2007 displaystyle forces more assemblies or just more code to be loaded into memory, which kinda makes sense, since it has to load up the Office color tables and has to do more appearance resolution. So pre-JITting the assemblies seems like it should solve the problem.
on my machine the result is the same, the second form pops much faster. I guess ILMerge and NGen for the infragistics dlls is probably the answer.
Thanks
I have tested the suggested by Mike and for the second form is displayed much faster than the first.
Let me know if the result is the same on your machine.
What happens if you launch a second instance of the dialog from the first one? Like put a button on the dialog and have it create a new instance of the same form class and then show it. Do you get the same delay?
If so, then this sounds like it's something we need to look into to see if we can make it more efficient. You might also want to try turning on Exception handling in Visual Studio to see if there are exceptions that are occurring and being caught - that might be slowing things down.
If the second form displays significantly faster than the first one, then my guess is that this is a JITting issue with DotNet loading assemblies into memory.