I spent a long time staring at Sean's gprof output: 1.7: 0.75 9.23 0.08 77538 0.00 0.00 EngineBuffer::process(float const*, float const*, int) 0.00 10.61 0.00 1747 0.00 0.00 Reader::wake() trunk: 0.10 9.71 0.01 65282 0.00 0.00 EngineBuffer::process(float const*, float const*, int) 0.00 9.91 0.00 65284 0.00 0.00 CachingReader::wake()
Basically, in trunk, the reader is woken up 100% of the time (out of 65282 calls). In 1.7 the reader is woken up 2.2% of the time. And I know why.. In 1.7, the reader was only woken up /if/ there was work to be done. In trunk, we wake the reader up because it has new hints to process, and let the reader be the determiner of whether or not it has work to do. My current theory is that (especially on single CPU systems) having another thread firing immediately after the audio callback /every time/ will starve Mixxx of its ability to do other things during the off-time following the callback. The best way to fix this that I can think of is to do hint processing for the reader in the audio callback thread. We will check that all the appropriate sections of the song are in memory, and if there is something to read from file (and only if), then we wake the reader up. I'll commit a fix that changes it to this scheme. Hopefully everyone experiencing performance regressions will notice an improvement. RJ Albert Santoni wrote: > Hi guys, > > Sean did some profiling to see if we could tell why there's an alleged > performance difference between the PortMIDI branch and trunk, and the > processed log files are attached. Nothing major jumped out at me when > I looked at them, but another set of eyes on them wouldn't hurt. > > Thanks, > Albert > > > ---------- Forwarded message ---------- > From: Sean M. Pappalardo - D.J. Pegasus <[email protected]> > Date: Fri, Dec 18, 2009 at 3:49 AM > Subject: gprof outputs > To: Albert Santoni <[email protected]> > > > Hello. > > Attached are the outputs from gprof on my Athlon XP-M laptop. I did > trunk, the PortMIDI branch, and the 1.7 branch, all compiled with > optimize=0, tuned=0 and asmlib=0. All were run with just one SCS.3d > attached. I used vinyl3 mode to select & load an MP3 file that hadn't > been analyzed, then played it and scratched it for a minute or so, > then closed Mixxx. > > I also noticed that the playposition-based scratching (vinyl2 mode > (purple)) no longer works in trunk/portMidi. I suppose that isn't too > surprising since it's a big hack anyway. :) > > Let me know what you find out. Nothing is obvious to me, looking at > these quickly. > > Sean > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Mixxx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ Mixxx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mixxx-devel
