From: Keith W. <ke...@va...> - 2000-06-16 21:58:37
|
Thomas Hellstrom wrote: > > Keith Whitwell wrote: > > > Thomas Hellstrom wrote: > > > > > > Hi, again! > > > > > > Keith Whitwell wrote: > > > > > > > Thomas Hellstrom wrote: > > > > > > > > > Hi, Keith. > > > > > > > > > > I did some timings with somon/soprof. I tested the following three cases: > > > > > > > > > > 1: > > > > > glPolygonMode(GL_FRONT_AND_BACK,GL_FILL) > > > > > glCallList(object) > > > > > > > > > > The display list is composed of GL_TRIANGLES > > > > > one at a time between each glBegin and glEnd calls. > > > > > The run was quite fast. Timings in attached file filledtiming. > > > > > Most time spent in a select call which from strace seems to be fd 4 wich, again > > > > > from strace, seems to be > > > > > /dev/dri/card0. Timing in attached file 'filledtiming' > > > > > > > > Try to track this down. I've only seen select take this sort of time in > > > > applications which call it too many times - it really should just sleep for > > > > most of the time, and shouldn't show up (very high) in profiling. If it is > > > > being used to poll the fd's without a reasonable timeout, and called often (eg > > > > in an event-dispatch loop), you can get this type of result. Select is > > > > probably being called with a few fd's, ours being just one of them. > > > > > > > > > > Yep, you're right, but the long time spent in the select call I think stems from the > > > QT main event loop, while the application loads the volume tetrahedal mesh using a > > > child thread. This actually takes quite some time and the main thread is idle waiting > > > for QT events. From what I saw in the soprof / somon README it counts elapsed time and > > > not CPU time so I don't think this is an important issue. At least it does not seem > > > related to the dri / drm driver. > > > > It counts CPU time, I'm pretty sure. > > > > Keith > > Excerpt from the somon README: > > "Since the monitor program, somon, uses the real time timer, you will > get inaccurate results if there are other programs using significant > CPU time. " > > And, for example > $ somon kdat (or another event driven program) > > and letting kdat idle for some time will give a very high select count and thus percentage. > How odd, and at the same time interesting. I'll have to look through the code more closely. Keith |