Re: Performance problem with PF 2.2

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.engr.sgi.com)
Thu, 28 May 1998 01:05:49 -0700

> Subject: Performance problem with PF 2.2
->
->Hello,
->
->We are in the process of upgrading our application from Performer 2.1 to 2.2;
->the upgrade was very straight forward code wise but we are having a problem
->with performance. The lost in performance occurs in the Performer APP stage
->process. In PF 2.1, the application APP thread runs at 7-8 msec while in PF
->2.2, it runs at 12-14 msec.
->
->Performance tests on those two versions were made on the same machine
->(ONYX2/4CPU/IR-2RM7/IRIX6.4).
->
->I thus made test comparison between the application versions and have noticed
->bizarre calls that are made in the PF 2.2 version of the software. Complete
->analysis results are available in the attachment. Analysis was made with
->speedshop, par and dbx. It shows that the 2.2 version is updating the Performer
->output window position through the X server. This is somehow annoying.
->
->The following calls are made in 2.2:
->
->pfPipeWindow::pf_updateWindow
->pfPipeWindow::pf_updateWindowOriginSize <= this is where it gets bizarre
->pfWindow::pr_updateScreenOrigin
->XTranslateCoordinates
->_XReply
-> _XRead
->_X11TransRead
->_X11TransShmBufRead
->_read
->
->The call to pfPipeWindow::pf_updateWindow() is made from pfSync(). In PF 2.1,
->no calls are made to pfWindow::pr_updateScreenOrigin() which happens in PF 2.2.

FYI, I can't catch perfly doing this beyond the initialization stage
or when I resize the window - can you? Or is this just in your app?

It sounds to me like someone is sending the perfly window size change
events, even if the window is not really changing size.
The above stuff is a response to us detecting the X event of a ConfigureNotify,
or GravityNotify event. Possibly you can use xscope to see if you are
seeing any other X events going around in the system.

->And also:
->
->pfPipeWindow::pf_updateWindow
->pfPipeWindow::pf_updateWindowOriginSize <= and again here
->XGetGeometry
->_XReply
->_XRead
->_XWaitForReadable
->_select
->
->The comparison tests were made on the SAME machine which does not eliminate the
->fact that this problem could be caused by the machine configuration interaction
->with PF 2.2.
->
->Nevertheless, further testing showed that this behavior does not occur on
->ONYX2/2CPU/IR and Octane platforms.

I am confused - are you sayint that the BAD behavior does or does not
occur on these platforms?

->
->My first guess on this is: bad HW configuration or unproper Performer
->initialization (DVR,GVO,????).

Doubt it.

->Any other suggestions ?
->
->And my questions are:
->
->- What could be causing the APP thread to reposition the screen position if it
->didn't change?
->- Why is a screen/window position update made through the X server instead of
->the local X display manager?

Only because we think we have been sent a reconfigure event which can
change the window position. The only trouble is that the screen
position of the window is not included in the event. We used to know
worry about that and just not know the position of the window on the
screen. We espcaped with that for a long time but folks finally
complained about other bugs and things we couldn't support without tracking
that at least about a change we have nominally been told about. This did
make our handling of those events slower, but any events coming through
is not a real-time situation anyway.

->- How can I get rid of this ??!

Well, you can turn off our listening to any events but this sounds like
a band-aid to a problem somewhere that needs to be fixed.

To make us deaf to events, include PFPWIN_TYPE_NOXEVENTS in your
pfPWinType specification. Now, we'll never know about the size
of a window unless you tell us with pfPWinSize.
If a user resizes a window, you'll have to tell us about it.
Again, use this if you are in an emergancy right now but lets find
the real bug.

Thanx!
src.

-- 
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com  (650) 933 - 1002  FAX: (650) 965 - 2658  MS 8U-590
-----{-----{---++at++   -----{----{---++at++   -----{----{---++at++   -----{----{---++at++
+>---- On May 27,  9:52am, Jean-Luc Dery wrote:
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:26 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.