forceGcCollect and Load factor too high

[peterainbow]

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

[peterainbow]

bump..

[Administrator]

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

[peterainbow]

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;

[Administrator]

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;
>

[peterainbow]

ooh hadn''t noticed it was disposable,

i''ll stick a using stement in then :-)