Performance Issues Closing Many Shells - Motif

This is a discussion on Performance Issues Closing Many Shells - Motif ; I am working with an application that was originally engineered 10+ years ago. The screens contain market data information for different currencies and credit ratings. When a currency screen is requested, the related ratings screen is also opened - but ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Performance Issues Closing Many Shells

  1. Performance Issues Closing Many Shells


    I am working with an application that was originally engineered 10+
    years ago. The screens contain market data information for different
    currencies and credit ratings. When a currency screen is requested, the
    related ratings screen is also opened - but not shown - and is populated
    with the relevant data. This is done so that when calculate the yield
    curves, all the relevant data windows are populated with the data that
    will be needed.

    We now have a new requirement which will end up creating 500 of these
    windows behind the scenes. I have all this working. My problem is that
    when I close the visible currency window I also need to close the
    invisible ratings window. This takes an inordinately long time. I am
    grasping at straws here but am I generating huge amounts of X traffic to
    the server as these hidden windows are closed? If so, is there
    anything that I can do about it.

    All of our windows are created as toplevelshells. Each shell is managed
    but not made visible. I am pretty sure that mappedwhenmanaged is true.

    I'd appreciate any help. If I am not expressing myself well or if the
    question is not phrased intelligently, please ask me a question and I'll
    get you the information that you need to help me.

    Thanks.

    ....Jake

    --
    Jake Colman
    Director of Software Development
    Principia Partners LLC
    101 West Elm Street
    Suite 620
    Conshohocken, PA 19428
    +1 (610) 755-9786
    www.principiapartners.com
    ** Posted from http://www.teranews.com **

  2. Re: Performance Issues Closing Many Shells

    On Sat, 12 Apr 2008 22:37:39 -0400, Jake Colman
    wrote:

    >
    >I am working with an application that was originally engineered 10+
    >years ago. The screens contain market data information for different
    >currencies and credit ratings. When a currency screen is requested, the
    >related ratings screen is also opened - but not shown - and is populated
    >with the relevant data. This is done so that when calculate the yield
    >curves, all the relevant data windows are populated with the data that
    >will be needed.
    >
    >We now have a new requirement which will end up creating 500 of these
    >windows behind the scenes. I have all this working. My problem is that
    >when I close the visible currency window I also need to close the
    >invisible ratings window. This takes an inordinately long time. I am
    >grasping at straws here but am I generating huge amounts of X traffic to
    >the server as these hidden windows are closed? If so, is there
    >anything that I can do about it.
    >
    >All of our windows are created as toplevelshells. Each shell is managed
    >but not made visible. I am pretty sure that mappedwhenmanaged is true.


    This sounds contradictory. mappedwhenmanaged && managed => mapped.

    >
    >I'd appreciate any help. If I am not expressing myself well or if the
    >question is not phrased intelligently, please ask me a question and I'll
    >get you the information that you need to help me.


    Just a wild-ass-guess: try creating the invisible windows without any
    decorations nor functions, and without any backingstore nor saveunder,
    and without icon.

    >
    >Thanks.
    >
    >...Jake


  3. Re: Performance Issues Closing Many Shells

    On Apr 14, 8:56 am, Michel Bardiaux wrote:
    > On Sat, 12 Apr 2008 22:37:39 -0400, Jake Colman
    > wrote:
    >
    >
    >
    >
    >
    > >I am working with an application that was originally engineered 10+
    > >years ago. The screens contain market data information for different
    > >currencies and credit ratings. When a currency screen is requested, the
    > >related ratings screen is also opened - but not shown - and is populated
    > >with the relevant data. This is done so that when calculate the yield
    > >curves, all the relevant data windows are populated with the data that
    > >will be needed.

    >
    > >We now have a new requirement which will end up creating 500 of these
    > >windows behind the scenes. I have all this working. My problem is that
    > >when I close the visible currency window I also need to close the
    > >invisible ratings window. This takes an inordinately long time. I am
    > >grasping at straws here but am I generating huge amounts of X traffic to
    > >the server as these hidden windows are closed? If so, is there
    > >anything that I can do about it.

    >
    > >All of our windows are created as toplevelshells. Each shell is managed
    > >but not made visible. I am pretty sure that mappedwhenmanaged is true.

    >
    > This sounds contradictory. mappedwhenmanaged && managed => mapped.
    >
    >
    >
    > >I'd appreciate any help. If I am not expressing myself well or if the
    > >question is not phrased intelligently, please ask me a question and I'll
    > >get you the information that you need to help me.

    >
    > Just a wild-ass-guess: try creating the invisible windows without any
    > decorations nor functions, and without any backingstore nor saveunder,
    > and without icon.
    >
    >
    >
    > >Thanks.

    >
    > >...Jake


    Unfortunately, that suggestion won't work. Although the windows are
    created invisibly, the user does have the option of viewing a given
    window to see the ratings information that has been loaded.
    Essentially, I need a way to delete shells so that they get deleted
    with a minimum of fuss. For example, if deleting a shell causes
    messages to be sent to the X Server, maybe I can tell shut down those
    messages until all windows are destroyed so that the X Server finds
    out all at once.

  4. Re: Performance Issues Closing Many Shells

    Jake Colman wrote:
    > I am working with an application that was originally engineered 10+
    > years ago. The screens contain market data information for different
    > currencies and credit ratings. When a currency screen is requested, the
    > related ratings screen is also opened - but not shown - and is populated
    > with the relevant data. This is done so that when calculate the yield
    > curves, all the relevant data windows are populated with the data that
    > will be needed.


    To me, this looks like a really bad case of failing to separate
    the interface from the underlying program logic.
    Like - a program, which uses the interface, to store data and
    temporary variables.
    This is just an observation, not criticism, I know how it is to maintain
    10 years old code, written by others.

    > We now have a new requirement which will end up creating 500 of these
    > windows behind the scenes. I have all this working. My problem is that
    > when I close the visible currency window I also need to close the
    > invisible ratings window. This takes an inordinately long time. I am
    > grasping at straws here but am I generating huge amounts of X traffic to
    > the server as these hidden windows are closed? If so, is there
    > anything that I can do about it.


    The correct thing to do (but you already know that),
    is to get rid of the hidden windows, and use
    proper data structures to fill in the data,
    and do the calculations without the interface. The problem with
    a kludge like hidden windows is that it does not scale,
    as you observe.

    If you think you can minimize code change by keeping
    bad architecture, and prefer solving the performance issues,
    I would suggest the following.
    Find out where the root of performance issues.
    Use a profiler, to see if it is your code or the libraries.

    for profiling, compile your program with
    -pg
    run the compiled program and then type
    gprof your_program >profile.txt
    you can even do per-line granulation by
    gprof -l your_program >profile_lines.txt

    Alternatively, use a debugger like ddd,
    run the program, issue the command which
    takes a lot of time, interrupt it (use toolbar
    on the right), and then examine stack by
    Status->Backtrace
    and you will have the full call trace of
    the current function. This is a fast and
    easy way of hitting hot spots in an
    unfamiliar program.

    Hope this helps,

    DuĊĦan Peterc
    http://www.arahne.si

+ Reply to Thread