> Richard, more research convinced me that applying this mod to all > locks was the better choice. Further profiling revealed that over 80% of > the locks toggled during network evaluations are associated with memory > allocation (amalloc, arealloc, afree) -- to my surprise, this is true even > for cached executions. This massive mallocing during cached passes is > another bottleneck to explore at some point.
I always suspected that some kind of mem allocation or copy wascausing latency in DX when running animation loops with the Seqencer. It will be very interesting to see how fast a simple loop now runs. It's great that you have uncovered this. > At any rate, relevent to your usage, memory allocation (and therefore > memory locking) is exposed through the libDX/libDXcallm APIs. So with the > patch I just cooked, the default locking policy defaults to enabled (used > by libDX/libDXcallm clients) as before. However, dxexec will flip this off > internally if it knows it doesn't need it. This sounds good. Thanks Richard
