Minor but fun changes today

[Arran Cudbard-Bell]

> On 11 Feb 2015, at 10:58, Arran Cudbard-Bell <a.cudbardb at freeradius.org> wrote:
> 
> 
>> On 11 Feb 2015, at 10:35, Phil Mayers <p.mayers at IMPERIAL.AC.UK> wrote:
>> 
>> On 10/02/15 22:05, Alan DeKok wrote:
>>> After some discussion, I moved the REQUESTs to using a talloc pool.
>>> i.e. it allocates a 32K chunk of memory for reach request, and then
>>> allocates REQUEST, RADIUS_PACKET, VALUE_PAIR, etc. within that.  If
>>> the pool runs out of memory, talloc() will fall back to using malloc.
>>> So there’s no downside to this.  We’ve made a few other minor
>>> changes, too.
>>> 
>>> Preliminary performance tests show a 35% decrease in time (clock
>>> cycles, via valgrind) to process the default configuration, with one
>>> user:
>> 
>> Cool. I was going to suggest a talloc_pool() for REQUEST's a while back but never got round to doing any measurement.
>> 
>> I guess the pool size could be a global but it's almost certainly unnecessary - most requests won't be around for long enough for it to matter.
> 
> It'd be a bit of a pain to keep track TBH. You can use a single pool because of thread safety issues, so you'd need to keep track of the number of requests allocated.

*can't use. As you already know, as you were the one who discovered that particular issue :)

Arran Cudbard-Bell <a.cudbardb at freeradius.org>
FreeRADIUS development team

FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freeradius.org/pipermail/freeradius-devel/attachments/20150211/fbf48ff6/attachment.sig>