[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