libunwind-devel
[Top][All Lists]
Advanced

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

Re: [Libunwind-devel] Libunwind Performance Questions


From: Paul Pluzhnikov
Subject: Re: [Libunwind-devel] Libunwind Performance Questions
Date: Fri, 10 Jan 2014 09:19:48 -0800

On Thu, Jan 9, 2014 at 11:23 PM, Michael Sartain <address@hidden> wrote:

> The problem I'm just starting to investigate right now is performance on
> i386 - it's brutally slow. I've stepped through the various routines below
> and I believe there is quite a bit of extra work going on that we don't need
> since the only thing we care about are the instruction pointers.

We've had a similar problem a few years ago.

Effectively, libunwind tracks the entire register state, but for vast
majority of i386 and x86_64 frames, tracking {esp,ebp,eip} triplet is all
that's required to restore call stack (instruction pointers).

I had a local patch to disable tracking all the extra registers, and got
a nice speed up.

Later, Lassi Tuura contributed a "fast trace" patch for x86_64, which
made x86_64 much faster still:
http://lists.gnu.org/archive/html/libunwind-devel/2011-03/msg00042.html

This is likely why you find x86_64 variant fast enough, but i386 too slow.

Later still, I attempted a mechanical port of "fast trace" to x86:
http://lists.nongnu.org/archive/html/libunwind-devel/2011-11/msg00022.html

Sorry I didn't finish it -- we've run into some other difficulties using
libunwind; in particular the fact that glibc lacked async-signal safe TLS
(our major use is unwinding from within malloc, and that doesn't play
well with libunwind using pthread_setspecific / __thread variables that
themselves call into malloc).

Hope this helps.
-- 
Paul Pluzhnikov



reply via email to

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