[Metakit] closing big file : slow

[Riccardo Cohen]

Thanks for the answer.
I'll bet for memory problems. I use v2.4.9.3 downloaded, and only the release library (even when I'm 
in debug).
But when the application is not running in visual studio (debug mode), the close takes 30 sec, when 
running the same app in visual studio (degugging), it takes >1 min.

I can't see why the storage walk through all subviews if I opened the file in read only (c4_Storage 
sto(vxg->get_nativesys_(),false);), is it to free something ?

I'll investigate further. Thank you.

Jean-Claude Wippler wrote:

> Riccardo Cohen wrote:
> 
>> I have a big database :
>> - size = 3Mo
> 
> 
> That's small, actually.
> 
>> - tables   c4gis_param, c4gis_geo, c4gis_id
>> - c4gis_geo has 60rows, one field is a subview of 5 to 60 rows, in the 
>> subview one field is a subview of 10/50 rows
> 
> 
> So there are perhaps a few thousand non-empty subviews in all?
> 
>> In my code I simply create a storage and extract some piece of data 
>> from c4gis_param (small table):
>>
>>   if (vxg->is_file())
>>   {
>>     c4_Storage sto(vxg->get_nativesys_(),false);
>>     if (ok)
>>     {
>>       c4_GisSpace space;
>>       space.loadParams(sto); //this loads information
>>     }
>>   }
>>   art_delete(vxg);
>>
>> the destructor of "sto" is VERY slow (several minutes), here is the 
>> call stack when I break the app during process :
> 
> 
> Destruction tends to walk through all subviews, that's all I can think 
> of as reason for the slowness you describe.  Still, a few thousand 
> subviews really is not very much, and taking minutes to go through 
> everything sounds very strange.
> 
> Are you running the datafilde from a file server?  There might be a lot 
> of very small I/O requests.
> 
> Also, please be sure to use a recent version of MK (best one right now 
> is probably CVS head).  Subview handling is still being tweaked.
> 
>> Before making a separate test, does anybody have an idea of what's 
>> happening ?
> 
> 
> Another reason could be some performance problem with the memory 
> allocator.  Subviews tend to do a lot of small allocations.  You did not 
> mention column counts, but if there are many columns in the subviews, 
> that will definitely lead to tons of tiny allocs/releases.
> 
> -jcw
> 
> _____________________________________________
> Metakit mailing list  -  Metakit at equi4.com
> http://www.equi4.com/mailman/listinfo/metakit
> 

-- 
Riccardo Cohen

Articque
Les Roches
37230 Fondettes
France
web = http://www.articque.com
tel: +33 02 47 49 90 49
fax: +33 02 47 49 91 49