Some changes coming in 17.03...

  • 4 Replies
  • 75 Views
*

ron

  • Administrator
  • Guru
  • *****
  • 3,195
Some changes coming in 17.03...
« on: March 20, 2017, 08:07:48 »
As we continually seek improvements in 8th's performance, we sometimes stumble on impressive gains.

The "pool" mechanism which 8th has used in all versions until now, is going to change in 17.03 to one which is faster and uses less memory.  To wit:

All items in 8th (strings, arrays, etc.) are allocated out of pools of that kind of item.  Currently, the pools are pre-allocated with a fixed number of items, and if more than that number of items is required, another pool of that size is allocated.  When an item's refcount becomes zero, it is available (and any data it had is released).

The new mechanism does not pre-allocate items, but rather allocates them on-demand.  Items with a 0 refcount are put on a 'free list', which is first checked when a new item is required.  If there are no items on the free list, then an item is allocated.

This has some advantages over the old method.  First, the startup time is lessened because less memory is allocated up-front.  Second, allocation of new items is faster, especially in the normal case of items being used and then released.  The speed gains depend on the usage pattern, and range from 5 - 50% (yes, that's right).

A further advantage is that the pool mechanism is much simpler.  Not that you care that much...

What does it mean for you?

In the main, you won't care.  However:
  • The "pool size" command-line option will be removed
  • The "G:pool-size" word will be deprecated; it will be removed in another version or two
  • The "G:(stats)" word is changing to show total items allocated and number of items on the free list; the 'number of pools' is always '1'
  • Another word will be added to force deallocation of items on the free list (for a particular pool)

*

bugmagnet

  • Master
  • ****
  • 252
  • Software Engineer, Propelis P/L
Re: Some changes coming in 17.03...
« Reply #1 on: March 21, 2017, 06:43:48 »
Impressive! Good news all round.

Bruce/bugmagnet

*

RichAMead

  • beta
  • Guru
  • *****
  • 586
  • "We all live in a big black hole. No, really."
Re: Some changes coming in 17.03...
« Reply #2 on: March 23, 2017, 02:49:33 »
It would be great to have a way to request pre-allocation (onto the free list presumably) of a specified number of items - for those applications that have either an 'initial loading' of some ("large") number of items, or which otherwise are known to maintain a "large" number of some item type for the life of the app...

*

ron

  • Administrator
  • Guru
  • *****
  • 3,195
Re: Some changes coming in 17.03...
« Reply #3 on: March 23, 2017, 04:39:50 »
I suppose I could make "pool-size" pre-allocate N items and put them on the free list...

*

ron

  • Administrator
  • Guru
  • *****
  • 3,195
Re: Some changes coming in 17.03...
« Reply #4 on: Yesterday at 10:13:42 »
I just tested a version where 'pool-size' is a no-op vs. one where it pre-allocates N items.  There was no noticeable performance difference overall, despite trying to force bad results.

The reason there's no performance difference is that in the first case, the allocation cost is amortized over the entire run-time, while in the second case it happens up-front. 

It should not make any difference in practical terms in any event.  So 'pool-size' will be deprecated, since it will be a no-op