Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2008-10

New object created in custom pool

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

JoshyFun

Hello FPC-Pascal,

My application will create thousands of small objects of the same class, this objects are not created or destroyed in a row, so memory fragmentation could becomes a serious problem after some time.

My question is: Is there any way to override the object creation to use a specific memory block ? This means, I plan to get a quite big bunch of continuos memory block at the beginning to allocate the needed space for all objects of that specific class and assign slots "manually" and reduce the memory fragmentation.

In other words, is there any way to write something like overriding the create method like:

constructor MyObject.Create()
begin
     result:=GetMem(sizeof(myobject));
end;

Thank you.

Best regards, JoshyFun

Reply by email

Vincent Snijders
to JoshyFun
JoshyFun wrote 19 lines
Hello FPC-Pascal, My application will create thousands of small objects of the same class, this objects are not created or destroyed in a row, so memory fragmentation could becomes a serious problem after some time. My question is: Is there any way to override the object creation to use a specific memory block ? This means, I plan to get a quite big bunch of continuos memory block at the beginning to allocate the needed space for all objects of that specific class and assign slots "manually" and reduce the memory fragmentation. In other words, is there any way to write something like overriding the create method like: constructor MyObject.Create() begin result:=GetMem(sizeof(myobject)); end;
You can override class function TObject.NewInstance : tobject;

For allocating the memory, you could use a special memory manager from pooledmm: http://lazarus-ccr.sourceforge.net/docs/fcl/pooledmm/index-4.html

Vincent

Reply by email

Florian Klaempfl
to JoshyFun: My application will create thousands of small objects of the same class, this objects are…
Show quoted text 5 lines
Hello FPC-Pascal, My application will create thousands of small objects of the same class, this objects are not created or destroyed in a row, so memory fragmentation could becomes a serious problem after some time.

Since the fpc heap manager itself pools, this should be a non issue.

Show quoted text 17 lines
My question is: Is there any way to override the object creation to use a specific memory block ? This means, I plan to get a quite big bunch of continuos memory block at the beginning to allocate the needed space for all objects of that specific class and assign slots "manually" and reduce the memory fragmentation. In other words, is there any way to write something like overriding the create method like: constructor MyObject.Create() begin result:=GetMem(sizeof(myobject)); end; Thank you.

Reply by email

Jonas Maebe
to Florian Klaempfl
Florian Klaempfl wrote 8 lines
JoshyFun schrieb: > Hello FPC-Pascal, > > My application will create thousands of small objects of the same > class, this objects are not created or destroyed in a row, so memory > fragmentation could becomes a serious problem after some time. Since the fpc heap manager itself pools, this should be a non issue.

It depends on how small the instances are.

Jonas

Reply by email

JoshyFun
to Jonas Maebe

Hello Jonas,

you wrote
>> My application will create thousands of small objects of the same >> class, this objects are not created or destroyed in a row, so memory >> fragmentation could becomes a serious problem after some time. > Since the fpc heap manager itself pools, this should be a non issue.

JM> It depends on how small the instances are.

The "problem" is that most objects are quite small, two pointers and two int64 values (maybe 2 pointers more in a near future), but it must be a class instead a record because it could be overriden and specialized for other minor tasks (minor in the
amount of created objects). The big "but" is that the creation of this objects will be in blocks of around 100 in average and every each block some big objects are created and many times allocation pages seens to be only half filled using the calculator and a rude aproximation, so I'll try to put all the small objects in a single block and see what happends with the memory (and also learn a bit more about fpc ;) ).

Best regards, JoshyFun

Reply by email

Jonas Maebe
to JoshyFun: JM> It depends on how small the instances are. The "problem" is that most objects are…
JoshyFun wrote 17 lines
Hello Jonas, Tuesday, October 28, 2008, 4:24:56 PM, you wrote: >>> My application will create thousands of small objects of the same >>> class, this objects are not created or destroyed in a row, so >>> memory >>> fragmentation could becomes a serious problem after some time. >> Since the fpc heap manager itself pools, this should be a non issue. JM> It depends on how small the instances are. The "problem" is that most objects are quite small, two pointers and two int64 values (maybe 2 pointers more in a near future), but it must be a class instead a record because it could be overriden and specialized for other minor tasks (minor in the amount of created objects). The big "but" is that the creation of this objects will be in blocks of around 100

100 bytes and smaller are most certainly handled using pools by FC's heap manager.

in average and every each block some big objects are created and many times allocation pages seens to be only half filled using the calculator

The calculator and which base size? Did you call instancesize to see how much space is required for each instance?

Jonas

Reply by email

JoshyFun
to Jonas Maebe

Hello Jonas,

Tuesday, October 28, 2008, 4:58:04 PM, you wrote:

JM> 100 bytes and smaller are most certainly handled using pools by FC's JM> heap manager.

This code is partially inherited from a Delphi one, so the test has been performed a few months ago using D7, maybe the fpc behavior is better.

> block some big objects are created and many times allocation pages > seens to be only half filled using the calculator

JM> The calculator and which base size? Did you call instancesize to see JM> how much space is required for each instance?

The rough calculation has been performed (more or less, you know some months ago, but now I'm porting this piece of code) using the instancesize rounded to 8 bytes align and running a synthetic do/while that tries to simulate the creating/destroy after around 12 hours of heavy load. The final result taking the currently allocated memory (at the end) and adding 2 pointers for block index was that the used memory is around 80% more than the needed.

Running the same do/while but without destroy any object and creating first the small objects and finally the large objects to end with the same amount of objects says that the memory occupation was only around 15% in excess.

I'll search the hard disk for the test routine, maybe it is still somewhere in the HD.

Best regards, JoshyFun

Reply by email

Knuckles
to JoshyFun: JM> It depends on how small the instances are. The "problem" is that most objects are…

JoshyFun пишет:

Show quoted text 11 lines
The "problem" is that most objects are quite small, two pointers and two int64 values (maybe 2 pointers more in a near future), but it must be a class instead a record because it could be overriden and specialized for other minor tasks (minor in the amount of created objects). The big "but" is that the creation of this objects will be in blocks of around 100 in average and every each block some big objects are created and many times allocation pages seens to be only half filled using the calculator and a rude aproximation, so I'll try to put all the small objects in a single block and see what happends with the memory (and also learn a bit more about fpc ;) ).

I suppose you should really take a look at the GoF's flyweight design pattern. If I understood you right, it's exactly what you want. The trick is (in short): You create only a few objects which in turn don't store all information inside, but rather use an outer storage - so called context. In your case it can be an array of records with those pointers and Ints. When you intend to use a flyweight, you give it a pointer to a needed context (buffer cell). So maybe you can even create only 1 instance of a needed class. The buffer of contexts can be easily allocated without fragmentation (use array or vector).

Reply by email