Will generated stack traces be different that --- Ömer Sinan Ağacan http://osa1.net
2014-08-13 19:56 GMT+03:00 Johan Tibell <johan.tib...@gmail.com>: > Yes, it doesn't use any code modification so it doesn't have runtime > overhead (except when generating the actual trace) or interfere with > compiler optimizations. In other words you can actually have it enabled at > all time. It only requires that you compile with -g, just like with a C > compiler. > > > On Wed, Aug 13, 2014 at 6:45 PM, Ömer Sinan Ağacan <omeraga...@gmail.com> > wrote: >> >> Is this stack trace support different than what we have currently? >> (e.g. the one implemented with GHC.Stack and cost centers) >> >> --- >> Ömer Sinan Ağacan >> http://osa1.net >> >> >> 2014-08-13 18:02 GMT+03:00 Johan Tibell <johan.tib...@gmail.com>: >> > Hi, >> > >> > How's the integration of DWARF support coming along? It's probably one >> > of >> > the most important improvements to the runtime in quite some time since >> > unlocks *two* important features, namely >> > >> > * trustworthy profiling (using e.g. Linux perf events and other >> > low-overhead, code preserving, sampling profilers), and >> > * stack traces. >> > >> > The former is really important to move our core libraries performance up >> > a >> > notch. Right now -prof is too invasive for it to be useful when >> > evaluating >> > the hotspots in these libraries (which are already often heavily tuned). >> > >> > The latter one is really important for real life Haskell on the server, >> > where you can sometimes can get some crash that only happens once a day >> > under very specific conditions. Knowing where the crash happens is then >> > *very* useful. >> > >> > -- Johan >> > >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs@haskell.org >> > http://www.haskell.org/mailman/listinfo/ghc-devs >> > > > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs