[MOAB-dev] iMesh_stepIter

[Steve Jackson]

Hi Jim,

Please disregard my earlier complaints about performance: apparently I had neglected to update my MOAB past the critical r5407, so every call I was making to stepIter() was a linear-time operation.  Mea culpa.  With the latest MOAB, my 100x100x100 iteration finishes in under 20 seconds.

A stepIter() for non-array iterators would still be useful to me, but chiefly for code clarity purposes rather than essential performance gains.
~S

On Feb 29, 2012, at 12:56 , Steve Jackson wrote:

> 
> On Feb 29, 2012, at 12:42 , James Porter wrote:
> 
>> On Wed, 2012-02-29 at 10:33 -0600, Steve Jackson wrote:
>>> After using pytaps to build a structured mesh of size 100x100x100, I
>>> walked over the whole mesh in a non-standard iteration order.  My
>>> iteration algorithm works as follows:
>>> 
>>> * Find the i,j,k coordinates of the next mesh element.
>>> * Compute N, the offset from the zeroth hexahedron in the mesh, based
>>> on i, j, and k.
>>> * Advance a pytaps array iterator N steps using a single call to
>>> stepIter.
>>> * Return the first item from this pytaps iterator, and reset the
>>> iterator.
>>> 
>>> The bad news: while a standard pytaps iterator can walk over a 1
>>> million element mesh in under a second, this customized approach takes
>>> more than ten minutes.
>> 
>> Do you know where the bottleneck in your algorithm is?
> 
> I believe it's in the iterator functions:
> 
> * If I only compute each N, the algorithm takes 15 seconds for 1M elements.  (Slow, but not beyond reason.)
> * But if I use each computed N to access the pytaps iterator, resetting the iterator each time, it takes 800 seconds.
> 
> I'm not sure which of the iterator functions (stepIter, next, or reset) is the slowest.   My system, unfortunately, doesn't seem to have the python profile package installed.  I can get you the code if you're interested in trying it.
> 
> (I realize there's a more efficient algorithm that only calls reset() when N is smaller than the previous N, and advances by (N - last_N) otherwise.  But I can't imagine that'd give me any better than a 2x speedup, and I need at least a 30x speedup.)
> ~S