Welcome, Guest. Please login or register.

Author Topic: Memory Pool performance  (Read 2174 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show only replies by Karlos
Memory Pool performance
« on: August 09, 2003, 11:21:13 PM »
Hi all,

Does anybody know if there is a golden puddlesize / threshold size ratio for exec v39+ pooled memory allocator?

I am fine tuning some low level code that needs to allocate/free lots of small objects as well has handling less frequent large allocations. Naturally the memory pool stands out as the OS provided mechanism for doing this without fragmenting the ram to bits.

I understand the CreatePool() parameters. My question is, are there any performance (read speed) concerns relating to the puddle size v threshold size?

As for choosing sensible values, my initial thought was to use the system's page size for the puddle size, but on reflection there is no guarentee that the puddles will be page aligned in any case.

Any suggestions?
int p; // A
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Memory Pool performance
« Reply #1 on: August 10, 2003, 12:43:00 AM »
Well...

Allocating new puddles can be time consuming. Thus if you are doing lot of allocations try minimize need of new puddles.

And for puddle sizes... I think it is better choose something like 4000 than 4200. Puddle sizes are always rounded up (if at all, on OS3 they arent).
My Amigas: A500, Mac Mini and PowerBook
 

Offline KarlosTopic starter

  • Sockologist
  • Global Moderator
  • Hero Member
  • *****
  • Join Date: Nov 2002
  • Posts: 16879
  • Country: gb
  • Thanked: 5 times
    • Show only replies by Karlos
Re: Memory Pool performance
« Reply #2 on: August 10, 2003, 01:50:52 AM »
Ok, makes sense.

When you allocate a large amount of memory (ie many times larger than the puddlesize), does that allocation take much longer than the equivalent AllocVec() call?

My understanding of the system is that it just allocates memory rounded to the puddlesize and allows sub allocations for several small objects within a single puddle..

-edit-

As for sizes, I was thinking to use a power of 2, eg 4096 or 8192, but that assumes the system doesnt store any info in the puddle itself.

The only documentation I have for the pool system is in the 3.5 includes&autodocs. Are there any better references available?
int p; // A
 

Offline itix

  • Hero Member
  • *****
  • Join Date: Oct 2002
  • Posts: 2380
    • Show only replies by itix
Re: Memory Pool performance
« Reply #3 on: August 10, 2003, 10:19:09 PM »
In general AllocPooled() is not probably any slower than AllocMem(). But of course if Exec finds out that all puddles are full then Exec must call AllocMem() as well. Thus it is always better oversize puddles bit rather than undersize.

Another thing is FreePooled(). FreeMem() is very simple call but FreePooled() must go through all puddles. In the worst case scenario calling FreePooled() can be very demanding. Piru investigated this issue.. Must ask him :-D

Quote

My understanding of the system is that it just allocates memory rounded to the puddlesize and allows sub allocations for several small objects within a single puddle..


Correct. If memory allocation is larger than treshold value then new puddle is allocated.
My Amigas: A500, Mac Mini and PowerBook