Chris Pelkie:
|> I'm faced with a 3000 module DX network used in a production app which
|>must be sped up (too slow).
|
|You inherited Mark's Mother of All Nets, I'm guessing? (:-)
Oh, you've heard of it? ;-) Guess it's reached urban legand status (and
it's still growing).
|I think I understand that it's the final playback that's the bottleneck
|from the user's point of view, correct? How about writing multiple frames
|out to MIFF (on the first pass)
That may be the way to go if the first pass times can't be improved much.
|So there's definitely hope if you want to locate loops and rewrite them as
|modules.
Thanks for the suggestions. In addition to what you've suggested, I've got
a number of other speed-up options to explore in mind:
1) Profiling/optimizing dxexec
Results show that locking, pixel packing, and malloc'ing appear to
be the biggest CPU hogs for "all-cached" net executions.
2) Semi-automatic translation to pure C (no DXLink)
Swapping mail with Mike Zeleznik sold me that a C-only dataflow would
solve this net's performance problems (with trade-offs).
3) The Switch/Route problem
DX apparently has to touch all of these on cached executions, for
reasons I don't appreciate. Address this, or reduce the number of
Switches and Routes in the main flow.
4) DXLink
Much of the network bulk associated with interactor scalar/string/
error processing can move into a client. Also this may make it
possible to segment the net into separately-executable nets.
5) Macros
Hide modules from the main flow.
And as you mentioned:
6) Custom modules
To handle loops and network chunks requiring a large number of
native DX modules.
7) Second-pass optimizations
Thanks again for the advice.
Randall
--
Randall Hopper (mailto:[EMAIL PROTECTED])
EPA Scientific Visualization Center
US EPA MD/24 ERC-1A; RTP, NC 27711
