Open catap opened 7 years ago
I made small research:
Oh, that's may fault then ...
@riataman I've opened a pull request https://github.com/riboseinc/retrace/pull/190 that contains first performance fix.
Performance significant improved, from I waited 40 minutes and interrupt
to 164.72 seconds
.
But I'm still thinking.
Well.. Looks like I found a dead-lock inside retrace if it running with gperftools.
Those are fun to track :)
@riataman but I will discribe the dead-lock later ;)
Sorry closed by mistake.
catap I don't think this was a performance fix per see, I don't think opening/closing a file should cause such a huge performance impact, I'm thinking there was a loop in there somewhere that was fixed by this.
Still a good fix :)
@riataman but since https://github.com/riboseinc/retrace/commit/4a23dda3c4636f084c4e89038f8667514a492b25 the code calls trace_printf
huge numbers of times.
And each time the code open and close the file, and when it close the file, it makes also flush for this file ;)
@riataman perhaps you can have a look to see how we can fix the performance impact of #143 ?
The tests done by @catap are very interesting because we can describe retrace's impact to executables in terms of multiples. Maybe we can even integrate these to CI tests (e.g., "not slower than 40x") and also describe in the README
.
Found one more possibility to huge performance impact: https://github.com/riboseinc/retrace/issues/208
When I run rnp tests without retrace it costs about 7 seconds:
Same test with retrace with config
logtofile,/dev/null
I interrupted after about 40 minutes.