Well, seems that detaching did the trick: Compilation time 0: 0.122659 Compilation time 1: 0.096926 Compilation time 2: 0.104063 Compilation time 3: 0.104441 Compilation time 4: 0.076877 Compilation time 5: 0.063249 Compilation time 6: 0.066638 Compilation time 7: 0.060207 Compilation time 8: 0.078996 Compilation time 9: 0.062104
It does not detach before handling the new process creation (judging by those times) but at least now I don't have that first time penalty. And thank for the offer but I think that changing Dyninst internals is out of my scope for now :) Thank you very much, Gerard 2015-01-29 19:41 GMT+01:00 Matthew LeGendre <[email protected]>: > > I think using a callback that detaches on fork would remove that > first-time penalty. > > Since Dyninst follows forks and execs by default, it's opening and parsing > the gcc executable when your application calls system(). Dyninst is > caching the results of its open and parse, so the subsequent invocations > are happening much faster. > > If you start detaching immediately after fork, then Dyninst should never > see the exec and will never parse the gcc executable. That said, I'm not > sure whether detach will improve the subsequent times. That'll depend on > whether Dyninst detaches faster than it handles new process creation (which > I've never measured). > > > As Bill mentioned, if Dyninst knew this fork() would be immediately > followed by an exec() it could make some optimizations and you'd probably > get close to the 0.03 ~ 0.04 times. Those optimizations could be turned > always on with a few small changes inside Dyninst, but the resulting > Dyninst would have unsafe behavior on apps that fork() without exec(). I > could point you at what to change, but it's getting into unsupported > territory. > > -Matt > > > On Thu, 29 Jan 2015, Gerard wrote: > >> Hi, >> Thanks for your answers. I'll try using a callback. >> >> I'm instrumenting a process that at some point compiles a code invoking >> gcc trough the system() function. I have made more tests and I see that the >> slow down is worse in the >> first call, does this makes sense? >> >> Those are the times that I observe while I'm instrumenting with dyninst >> (just the function that wraps the call to system()): >> >> Compilation time 0: 0.984198 >> Compilation time 1: 0.080625 >> Compilation time 2: 0.084245 >> Compilation time 3: 0.077437 >> Compilation time 4: 0.084535 >> Compilation time 5: 0.111851 >> Compilation time 6: 0.087407 >> Compilation time 7: 0.090078 >> Compilation time 8: 0.093158 >> Compilation time 9: 0.075809 >> >> While without dyninst the times are between 0.03 ~ 0.04 seconds. >> >> Gerard >> >> 2015-01-20 18:37 GMT+01:00 Bill Williams <[email protected]>: >> On 01/20/2015 11:22 AM, Matthew LeGendre wrote: >> >> The closest you can get is to register a callback that >> triggers on fork, >> then detach from the child in that callback. >> >> There's not really a faster way to disable tracing of >> children, as >> Dyninst needs to clean its instrumentation from child >> processes before >> detaching. >> >> I'm also somewhat curious what aspect of Dyninst's fork behavior is >> responsible for the slowdown you're observing, Gerard. Can you tell us a >> bit about your use >> case and more details about why/how Dyninst is responsible for this >> slowdown? >> >> Matt is of course correct that if this is a fork without a >> subsequent exec, that it's necessary for Dyninst to remove all its >> instrumentation. In principle, if we >> knew that all forks would be followed either by an immediate exec >> or a crash, we could dispense with that instrumentation entirely, but in >> practice that's not >> generally a safe assumption. >> >> Another option that may be effective is performing the initial >> instrumentation with binary rewriting...that should have substantially >> better behavior for what you >> want re: fork/exec. >> >> -Matt >> >> On Mon, 19 Jan 2015, Gerard wrote: >> Hello, >> Is it possible to not trace the children created by a >> mutatee? I want to >> avoid the time penalty introduced by dyninst when a >> mutatee creates a >> children. >> >> Thanks, >> >> Gerard >> >> >> _______________________________________________ >> Dyninst-api mailing list >> [email protected] >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> >> >> >> -- >> --bw >> >> Bill Williams >> Paradyn Project >> [email protected] >> >> >> >>
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
