i'm trying to figure out the best numbers to use for setting up a sorted collection... i'm just not understanding the numbers i'm getting from the heapdump unit at the end of the run...

i have two collections (/details at the end/)... these collections can be pretty "large" (~40000 entries for one collection, ~20000 for the other)... using the *exact same data* in both cases, if i use this code to set them up...

   aTLEColl    := New(PTLEColl, Init(16384,64));
   aSatCatColl := New(PSCColl, Init(16384,64));

i get numbers like this (from the heapdump)

Heap dump by heaptrc unit
8205341 memory blocks allocated : 333112907/357222392 8205341 memory blocks freed : 333112907/357222392 0 unfreed memory blocks : 0
True heap size : 720896 (208 used in System startup) True free heap : 720688

but if i use this code to set up the collections...

   aTLEColl    := New(PTLEColl, Init(1,1));
   aSatCatColl := New(PSCColl, Init(1,1));

i get numbers like this (from the heapdump)

Heap dump by heaptrc unit
8260386 memory blocks allocated : 3874244611/3898464904 8260386 memory blocks freed : 3874244611/3898464904 0 unfreed memory blocks : 0
True heap size : 262144 (208 used in System startup) True free heap : 261936

*if i'm reading this properly*, what is confusing me is the first one allocates less memory blocks and uses more heap whereas the second one allocates (a lot) more memory blocks (55000 more??) but uses much less heap...

so i'm trying to figure out the best set of init numbers for the collections... i'm wanting the fastest run time with the smallest memory usage... am i understanding this correctly??

*collection details if needed*

   PSCColl    = ^TSCColl;
   TSCColl    = object(TSortedCollection)
                  Function Compare(Key1,Key2:Pointer):sw_integer; virtual;
                  Function KeyOf(Item:Pointer):Pointer; virtual;
                  Procedure Insert (Item:Pointer); virtual;
                end;
   PTLEColl   = ^TTLEColl;
   TTLEColl   = object(TSortedCollection)
                  Function Compare(Key1,Key2:Pointer):sw_integer; virtual;
                  Function KeyOf(Item:Pointer):Pointer; virtual;
                  Procedure Insert (Item:Pointer); virtual;
                end;

PSCColl contains these...

   PSCRec     = ^TSCRec;
   TSCRec     = object(TObject)
                  catnbr   : Tcat_nbr;
                  satname  : Tsat_name;
                  inorbit  : boolean;
                  constructor Init(cnbr,sname:string; iorbit:boolean);
                  destructor Done; virtual;
                end;

PTLEColl contains these...

   PTLERec    = ^TTLERec;
   TTLERec    = object(TObject)
                  satname  : Tsat_name;
                  satdata1 : Tline_data;
                  satdata2 : Tline_data;
                  catnbr   : Tcat_nbr;
                  epoch    : double;
                  constructor Init(sname,sdata1,sdata2,cnbr:string; edate:double);
                  destructor Done; virtual;
                end;

they hold these data types...

   Tcat_nbr   = pstring;   // 5 characters
   Tsat_name  = pstring;   // 24 characters
   Tline_data = pstring;   // 69 characters

The number of blocks is higher in the second case because a new memory block is allocated for each record added to the collection (initial collection size is 1, the size is increased by one record whenever the allocated size is fully used and a new record shall be added). However, I'm not clear why you think that less heap is used in the second case?

so i'm trying to figure out the best set of init numbers for the collections... i'm wanting the fastest run time with the smallest memory usage... am i understanding this correctly??

Considering the number of records you suggested above, I'd go for something like 20000 records as the initial collection size and e.g. 2000 or even 5000 as the increment.

Tomas

On 10/27/2012 16:23, Tomas Hajny wrote:
[trim]

ahhh... ok, so that's "number of records" to start with and "number of records to increase by"...

> However, I'm not clear why you think that less heap is used in the > second case?

because "true heap size" is different between them... i am thinking that this is the total amount of heap used by the program during its run??

ok... i'll give that a try and see what happens... thanks very much for your response!

FWIW: i had asked this some several months back but was probably not as clear in my request... it may have also been in the wrong area but i didn't get any response to it so i just left it alone to ask later ;)

Indeed, as described in our documentation (in particular part related to TCollection.Init in unit Objects - quoted including the typo there ;-) ):

Declaration: constructor Init(ALimit: Sw_Integer;ADelta: Sw_Integer) Visibility: default
Description: Init initializes a new instance of a collection. It sets the (initial) maximum number of items in the collection to ALimit. ADelta is the increase size : The number of memory places that will be allocatiod in case ALimit is reached, and another element is added to the collection.

TSortedCollection.Init uses the same parameters with the same meaning as constructor of its ancestor.

No, it's just the amount of memory allocated for heap at the given point in time. The real amount of memory used must be much higher obviously (the number of records you mentioned multiplied by pure size of the stored data already gives a bigger number even without counting any overhead for storing all the pointers, VMT tables, etc.).

.
.

FWIW: i had asked this some several months back but was probably not as clear in my request... it may have also been in the wrong area but i didn't get any response to it so i just left it alone to ask later ;)

Well, there may be various reasons for not getting responses. I don't remember having seen such a message so I personally probably missed it for whatever reason. Not so many people use (or even know) the original TP/BP object model and the objects included in our RTL nowadays so that may also impact the response rate. In any case, asking again and possibly reformulating the question a bit never hurts. ;-)

Tomas