3 ms·
You know, it is pretty funny that some people on Reddit linked to a talk from aaronsw (AKA tenderlove) about Ruby on Rails performance issues and performance re
by 616c 12y ago
You know, it is pretty funny that some people on Reddit linked to a talk from aaronsw (AKA tenderlove) about Ruby on Rails performance issues and performance regressions. In the middle of the video he cracks up and points out he went down a tangent path because that Ruby profile was built of a gem that called into Ruby MRI's C API. So he worked his way through the gem developer, and then the Ruby dev who wrote the C API. Neither knew what was going on.
https://www.youtube.com/watch?feature=player_detailpage&v=JMGmaRZtgM8#t=1450 https://www.youtube.com/watch?feature=player_detailpage&v=JM...
Turns on the profiling data where there was a discrepancy between CPU times and Wall times was only OS X because of a problem with a trap() call on OS X specifically, not any other platform. His moral of the story: even profilers have bugs.
https://www.youtube.com/watch?feature=player_detailpage&v=JMGmaRZtgM8#t=1608 https://www.youtube.com/watch?feature=player_detailpage&v=JM...
I think I am seeing a pattern today.
- 0x0 12y agops I think you got some aarons mixed up
- 616c 12y agoYes, I did get the Aarons mixed up. Thanks to both of you for noticing.
- snewman 12y agoProfilers lie all the time. Usually it's not so much a bug, as a known limitation of the profiling approach. E.g. profilers that annotate methods with entry / exit code, inflate the runtime of small methods. Profiles that rely on CPU sampling, can be vulnerable to correlations with the sampling schedule. And so forth. The moral is to always do a reality check on whatever your profiler is telling you.
- kenbellows 12y agoJust for the sake of it, that is Aaron Patterson (yes, aka Tenderlove), but it is not aaronsw, a moniker referring to the late Aaron Swartz.