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 **
>
>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.
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