We use cookies to give you the best experience on our website. If you continue to browse, then you agree to our privacy policy and cookie policy. Image for the cookie policy date

forceGcCollect and Load factor too high

Hi, We''re using a grid in virtual mode and everynow and then we get the ''Hashtable insert failed. Load factor too high.'' Looking in the syncfusion source for GridVolatileData I found referneces to this and a mysterious member forceGcCollect, which it says should be changed if this happens. However we do not have access to this member. What should we do about this problem as it''s causing our reports to fail every now and then? cheers pete

5 Replies

PE peterainbow August 8, 2005 10:58 AM

bump..


AD Administrator Syncfusion Team August 8, 2005 01:25 PM

Pete, you can use reflection to modify this property. Example: void AdjustForceGcCollect(GridModel gridModel, int newValue) { GridVolatileData volatileData = gridModel.VolatileData as GridVolatileData; if (volatileData != null) { System.Reflection.FieldInfo fi = typeof(GridVolatileData).GetField("forceGcCollect", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic); if (fi != null) { fi.SetValue(volatileData, newValue); } } } public Form1() { // // Required for Windows Form Designer support // InitializeComponent(); AdjustForceGcCollect(this.gridControl1.Model, 2000); ... } We can also add code in the exception handler to automatically reduce the value to the current size of elements in the hashtable. But I am surprised this happens. The exception is only there because we thought there is a chance this happens if the garbage collection is not called early enough and the hashtable fills up to much. Do you hold onto style objects in your application? Thanks, Stefan


PE peterainbow August 9, 2005 04:44 AM

no we don''t hold onto style objects, at least not intentionally :-) do you think this could happen in a low memory situation? What we''re doing in our code is exporting a complete grid and it''s a very large grid ~200,000 rows in virtual mode. What i''m going to try and do is not use the grid indexer to get the data but go direct to our own querycell callback handler, which will be faster and won''t go through the style caching code. i''m testing something like ... GridStyleInfo style = new GridStyleInfo(new GridStyleInfoIdentity(gridControl1.Model.VolatileData, rowIndex, colIndex)); GridQueryCellInfoEventArgs args = new GridQueryCellInfoEventArgs( rowIndex , colIndex , style ); style.BeginInit(); this.GridQueryCellInfo( this , args ); style.EndInit(); return style.Text;


AD Administrator Syncfusion Team August 9, 2005 06:51 AM

Hi Pete, that should work. Since your code is creating the style you can also call Dispose() on the style object after you do not need it anymore. I don''t think you are holding onto objects. I guess it''s just the repeated call directly to the indexer within one proceedure that is causing the GC to be a bit behind. I think bypassing the indexer will speed up things for you since there is no need to cache these values. Stefan >no we don''t hold onto style objects, at least not intentionally :-) > >do you think this could happen in a low memory situation? > >What we''re doing in our code is exporting a complete grid and it''s a very large grid ~200,000 rows in virtual mode. > >What i''m going to try and do is not use the grid indexer to get the data but go direct to our own querycell callback handler, which will be faster and won''t go through the style caching code. > >i''m testing something like ... > >GridStyleInfo style = new GridStyleInfo(new GridStyleInfoIdentity(gridControl1.Model.VolatileData, rowIndex, colIndex)); >GridQueryCellInfoEventArgs args = new GridQueryCellInfoEventArgs( rowIndex , colIndex , style ); >style.BeginInit(); >this.GridQueryCellInfo( this , args ); >style.EndInit(); >return style.Text; >


PE peterainbow August 9, 2005 11:51 AM

ooh hadn''t noticed it was disposable, i''ll stick a using stement in then :-)

Loader.
Live Chat Icon For mobile
Up arrow icon