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
