libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libunwind-devel] Testing time


From: Arun Sharma
Subject: Re: [Libunwind-devel] Testing time
Date: Tue, 5 Apr 2011 22:17:01 -0700

I applied the getcontext lite patch with minor changes (mark the
symbol hidden and leave the namespace alone).

Still working on the other two.

 -Arun

On Fri, Apr 1, 2011 at 2:57 AM, Lassi Tuura <address@hidden> wrote:
> Hi,
>
>> I also applied two of your patches. 01-performance-optimisations.patch
>> is the only remaining patch in my inbox.
>
> Thanks!
>
> I refreshed the performance optimisation patch to reflect the current git 
> tree; attached at the end.
>
> There was also the trace-specific getcontext patch in another thread 
> ("Another optimisation for x86-64 fast trace"). I've attached it here again, 
> for completeness.
>
> In the mean time I've experimented with yet another change to the fast trace, 
> this time replacing the two-level hash table with a single-level one. This 
> doesn't use mempool but instead grabs a slab of memory use GET_MEMORY (= 
> mmap). Apart from the app-provided memory allocation hooks it's a bit more 
> like what Jason Evans submitted.
>
> This last one yields a fairly consistent ~5% improvement. I'm seeing this 
> taking our application (387M stack walks to profile memory allocations) to 
> 50-51 clock cycles per stack level (was ~53), or ~1320 cycles per walk (was 
> ~1400). The gain is largely from avoiding the double indirect memory access 
> in the hash code.
>
> I hope the last improvement is still acceptable even with using less of the 
> mempool stuff.
>
> I experimented with a number of other changes, none of which yield consistent 
> measurable improvement. I think with these changes the code is starting to be 
> at the limit of what can be achieved - or at least what I am capable of :-) 
> Per stack level time now mostly goes into a single hash table access plus 
> reading the saved register values off the stack; everything else contributes 
> little to the stack walk time (under heavy walking).
>
> Regards,
> Lassi
>
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]