I have opened a support case already (CAS-158181-J3X5V3) but wanted to post this publically to provide visibility for other users potentially facing this issue.
Since upgrading to the latest service release (15.1.20151.2055) our 32-bit applications are throwing OutOfMemoryExceptions and crashing all day long, and our 64-bit applications are ballooning in memory footprint and suffering significant performance degredation.
We just rolled back the Infragistics dlls back to the version prior to the SR and our applications are all performing as expected again (no changes to our application assemblies).
Looking at the diffs in the source code, there's a huge smell coming from DataPresenterBase.cs line 21835 -- InvalidateArrange() is now being called on the DataPresenterBase every time a scroll happens. MSDN STRONGLY discourages this: https://msdn.microsoft.com/en-us/library/system.windows.uielement.invalidatearrange(v=vs.110).aspx
"Frequent calls to InvalidateArrange or in particular to UpdateLayout have significant performance consequences. Therefore, avoid calling this method unless you absolutely require precise layout state for subsequent calls to other APIs in your code."
Hello,
Could you please share the stack trace of the error you are receiving after the update? Would you please also let me know which version you have used prior the update? This information is needed so I could investigate this issue further and the reason that might have cause it. Thank you.
Since this is an OutOfMemoryException the stack trace is largely irrelevant. It blows up in various unrelated places as memory is attempted to be allocated and does not point to the calls actually causing the memory consumption. I'm attempting to put together a sample application that demonstrates the issue but haven't had a lot of success. In the mean time we have now rolled back all of our production applications off the service release in question and have no issues (other than the known bugs that existed prior to this SR).
Hi,
I have contacted the development team regarding this issue and it was confirmed that the InvalidateArrange method could add some performance overhead (CPU activity) rather than resulting in OutOfMemory exception. It will be hard to investigate this further without a sample that reproduces this issue so I would like to thank you for your efforts to isolate it.I would also like to suggest you to use a memory profiling tool in order to check the type with the higher number of allocations. It will be also useful if you could share the results.
I am just checking if you had a chance to look into this and share a sample project and/or memory profiler result so we can try to assist you further on this.