You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Jeff Trawick <tr...@gmail.com> on 2013/03/16 15:34:19 UTC
bug 54572 -- move struct crypt_data allocation to heap
This would be good to resolve in 1.5.2.
Has anyone else evaluated this? I'm suspicious of the use of a global
pool in the reporter's patch vs. just using malloc() directly. I
guess the reason for using the pool is that the allocator may have
suitable buffers lying around, but you need one for the pool and one
for the structure instead of just getting one from malloc(). I
haven't tried any performance tests yet.
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 24 March 2013, Eric Covener wrote:
> >> Anyone has a system using CRYPTD to test this?
> >
> > AIX anyone?
>
> Poked around and CRYPTD stuff doesn't show up in my builds on AIX.
HP-UX uses CRYPTD according to google...
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Eric Covener <co...@gmail.com>.
>> Anyone has a system using CRYPTD to test this?
> AIX anyone?
Poked around and CRYPTD stuff doesn't show up in my builds on AIX.
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Mar 23, 2013 at 6:22 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Saturday 23 March 2013, Jeff Trawick wrote:
>> On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch <sf...@sfritsch.de>
> wrote:
>> > On Saturday 16 March 2013, Jeff Trawick wrote:
>> >> This would be good to resolve in 1.5.2.
>> >>
>> >> Has anyone else evaluated this? I'm suspicious of the use of a
>> >> global pool in the reporter's patch vs. just using malloc()
>> >> directly. I guess the reason for using the pool is that the
>> >> allocator may have suitable buffers lying around, but you need
>> >> one for the pool and one for the structure instead of just
>> >> getting one from malloc(). I haven't tried any performance
>> >> tests yet.
>> >
>> > An alternative would be using apr_allocator_alloc() directly
>> > (with the global pool's allocator). Creating a sub-pool seems
>> > more overhead than necessary. Not sure what is better, malloc()
>> > or apr_allocator_alloc().
>>
>> No good way to get to global_pool/global_allocator from outside
>> apr_pools.c AFAICT
>>
>> I think malloc() wins here...
>
> You are right. What about
>
> http://svn.apache.org/r1460243
Looks good here...
>
> Anyone has a system using CRYPTD to test this?
Not me (chuckle)...
AIX anyone?
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 23 March 2013, Jeff Trawick wrote:
> On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch <sf...@sfritsch.de>
wrote:
> > On Saturday 16 March 2013, Jeff Trawick wrote:
> >> This would be good to resolve in 1.5.2.
> >>
> >> Has anyone else evaluated this? I'm suspicious of the use of a
> >> global pool in the reporter's patch vs. just using malloc()
> >> directly. I guess the reason for using the pool is that the
> >> allocator may have suitable buffers lying around, but you need
> >> one for the pool and one for the structure instead of just
> >> getting one from malloc(). I haven't tried any performance
> >> tests yet.
> >
> > An alternative would be using apr_allocator_alloc() directly
> > (with the global pool's allocator). Creating a sub-pool seems
> > more overhead than necessary. Not sure what is better, malloc()
> > or apr_allocator_alloc().
>
> No good way to get to global_pool/global_allocator from outside
> apr_pools.c AFAICT
>
> I think malloc() wins here...
You are right. What about
http://svn.apache.org/r1460243
Anyone has a system using CRYPTD to test this?
Cheers,
Stefan
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Jeff Trawick <tr...@gmail.com>.
On Sat, Mar 23, 2013 at 12:01 PM, Stefan Fritsch <sf...@sfritsch.de> wrote:
> On Saturday 16 March 2013, Jeff Trawick wrote:
>> This would be good to resolve in 1.5.2.
>>
>> Has anyone else evaluated this? I'm suspicious of the use of a
>> global pool in the reporter's patch vs. just using malloc()
>> directly. I guess the reason for using the pool is that the
>> allocator may have suitable buffers lying around, but you need one
>> for the pool and one for the structure instead of just getting one
>> from malloc(). I haven't tried any performance tests yet.
>
> An alternative would be using apr_allocator_alloc() directly (with the
> global pool's allocator). Creating a sub-pool seems more overhead than
> necessary. Not sure what is better, malloc() or apr_allocator_alloc().
No good way to get to global_pool/global_allocator from outside
apr_pools.c AFAICT
I think malloc() wins here...
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: bug 54572 -- move struct crypt_data allocation to heap
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Saturday 16 March 2013, Jeff Trawick wrote:
> This would be good to resolve in 1.5.2.
>
> Has anyone else evaluated this? I'm suspicious of the use of a
> global pool in the reporter's patch vs. just using malloc()
> directly. I guess the reason for using the pool is that the
> allocator may have suitable buffers lying around, but you need one
> for the pool and one for the structure instead of just getting one
> from malloc(). I haven't tried any performance tests yet.
An alternative would be using apr_allocator_alloc() directly (with the
global pool's allocator). Creating a sub-pool seems more overhead than
necessary. Not sure what is better, malloc() or apr_allocator_alloc().