We are initializing the appearance for an editor control that we are using like this:
internal class HiddenLinkFormattedTextEditor : UltraFormattedTextEditor { internal HiddenLinkFormattedTextEditor() { var foreColor = Color.FromArgb(0xFF, 0x38, 0x43, 0x50); // DarkNavy this.ActiveLinkAppearance.ForeColor = foreColor; this.ActiveLinkAppearance.Cursor = Cursors.Arrow; this.LinkAppearance.ForeColor = foreColor; this.LinkAppearance.Cursor = Cursors.Arrow; this.HotTrackLinkAppearance.ForeColor = foreColor; this.HotTrackLinkAppearance.Cursor = Cursors.Arrow; this.VisitedLinkAppearance.ForeColor = foreColor; this.VisitedLinkAppearance.Cursor = Cursors.Arrow; this.VisitedLinksManager = null; this.UnderlineLinks = UnderlineLink.Never; }
In the performance profiler I see that the appearance calls are translated to 4 calls to Infragistics.Win.Appearance.set_ForeColor (obviously a static property) which takes about 1 second during startup of our application (probably because there are already a couple of instantiated and bound grids where this property then gets re-applied).
Is there a better way to do this? Since these are static properties - do I need to introduce my own marker variable that I set when I have gone through this initialization once (even if it looks like it is setting instance properties)?
Any other suggestions for optimizing performance for this initialization?
Please note: this particular method seems to have gotten slower compared to the pretty ancient version (IG 2011) that we have been using until recently.
Hello Uwe,
Thank you for contacting. Looking into the winform document here is a general Grid performance guide if you wants to have a look ,
https://ko.infragistics.com/community/forums/f/ultimate-ui-for-windows-forms/15306/wingrid-performance-guide
In terms of appearance performance we don’t have any document to give us this particular information.
May be try using app appstylist for the style and see if it give you better performance.
Also may i know how you are checking the performance? Can you share the sample to compare the behavior with Version 2011,
Its possible that since 2011 we have made lots of changes cause this behavior that i would need to test with your sample.
Regards,
Hello Deviya,
I have attached the sample project (very basic WinForms project which creates a form with embedded grid and binds some data). I have also taken profiles for the startup of this application with two versions of Infragistics:
This is the startup performance when using Infragistics 2011 (for this project):
And this is the counterpart for 2021:
There is about 400ms difference which does not sound like a lot but when you are trying to optimize launch times for an application each contribution becomes relevant.
In contrast to what I said above I don't think this is related to setting the ForeColor for the editor - it's just anything that triggers the initial call to Infragistics.WinAppStyling.StyleSetInfo.LoadContent.
Please let me know if there's something I can do to avoid the overhead (I see that most of the time is spent in ParseGlyphInfo).
GridPerfTest.zip
Thank you for the update and clear out that the issue is not due to ForeColor .
I discuss the matter with the developer and looking at the screenshots nothing has changed in the ParseSerializedObject code for like 15 years if we compare from 2011 to 2022 .
If you also look at the stack traces, they are the same until you get into the BinaryFormatter which appears to be where the slowdown is occurring. Microsoft has made some fixes in BinaryFormatter over the years, and my best guess is their changes to improve performance when deserializing larger objects has caused this slowdown with our smaller object.
So not sure if there is anything we could do about it. Also the screenshots shows the formatter inside our Binder code in the old code, but not in the new code. This doesn't say that its not being hit ,its just indicating that its not the biggest performance impact.
So may be you have to see where bigger impact of the performance is hitting to improve the code.
Let me know if you have further question or concern.
Divya Jain
No you don’t need to do any adjustment in the isl file.
So i am going to do performance profiling to see how long the process spends in each statement against different versions.
Testing against different versions should narrow down when it was introduced and I would log this behavior into our internal bug tracking system for the developer to look into the source code and see if there is something possibly could cause it and if we could improve it.
So here is the private case C-00223091 I have created for further investigation on this matter. I will keep updated the private case and would attach the bug number .
You can access the private case from your infragistics account at :
https://account.infragistics.com/support-cases
Thanks Divya, I have one question to your statement about the different stacks (starting at the BinaryFormatter.Deserialize call): is there a reason (given that all this was run on the same machine with the same version of the .NET Framework) that the deserialization of the GlyphInfo is doing different things with IG 2011 vs 2021? Is there potentially an adjustment that we have to do in the isl file (see example project) which would change how the actual deserialization works (i.e. using your Binder - which seems to be faster - instead of calling the generic ObjectReader?