Hi All,

I was just writing a bit of python code that goes through an object and creates a dictionary of attributes and vertex indices.

It works fine for small meshes(under 100k Points, but as you get bigger it inevitably gets slower. I've tracked the majority of the slowness to a couple of lines that is run many times (per vertex)

attribStack.append(v.point().attribValue(attr))
indexStack.append(v.point().number())


I think this is because of how HOM is accessing the info (or better, how I am accessing the info through HOM)

here is the code block :

attribStack = {}
indexStack = {}


index = 0
for attr in myGeo.pointAttribs():
if attr is not None:
name = attr.name()
attribStack =
indexStack =
#Here I am storing the Float type and size as a first element in the attribute
attribStack.append(str(attr.dataType())+str(attr.size()))
indexStack.append(str(attr.dataType())+str(attr.size()))
for prim in myGeo.prims():
for vid in xrange(prim.numVertices()):
# get vertex
v = prim.vertex(vid)
#Majority of slowness is here
attribStack.append(v.point().attribValue(attr))
indexStack.append(v.point().number())


The basic things that I need to happen are :

Create a list of values for each attrib
Create a point index on the vertices (for shared data)

Any thoughts on other ways to optimize this bit of code. perhaps I'm missing the obvious answer.



Cheers,
Ali

Yes, you're python-looping over call to HOM library. Not good.

Take a look on:
http://www.sidefx.com/docs/houdini12.1/hom/hou/Geometry#pointFloatAttribValuesAsString [sidefx.com]
http://www.sidefx.com/docs/houdini12.1/hom/hou/Geometry#primFloatAttribValuesAsString [sidefx.com]

or without “AsString” for little slower, yet as easy to use access to attributes.

SYmek
Yes, you're python-looping over call to HOM library. Not good.

Take a look on:
http://www.sidefx.com/docs/houdini12.1/hom/hou/Geometry#pointFloatAttribValuesAsString [sidefx.com]
http://www.sidefx.com/docs/houdini12.1/hom/hou/Geometry#primFloatAttribValuesAsString [sidefx.com]

or without “AsString” for little slower, yet as easy to use access to attributes.

hmmm… I hear a resounding… silly Peon …. :-)

Thanks for the pointer.

Perhaps the housekeeping is worth the speed increase.

Problem with the pointFloatAttribValues is that it returns a large list. so there is not differentiation between float1 float2, float3 just a bigger list.
so I may need to keep track of the attribute.size() as well and reorder a new list with the right grouping for easier access later. but doing that in python's data structures will be alot faster than going through HOM.

Ints and vectors are also just treated as floats by this function. so there is also that house keeping.

The next issue, is doing this for vertices (liek UVs). and I don't see any functions for getting this for verts.


Here is a quick implementation using the list. It runs about twice as fast.
But I still have the slowdown on verts.
HDK extension of HOM ?

attribStack = {}
indexStack = {}
vList=
startb = time.clock()
for attr in myGeo.pointAttribs():
name = attr.name()
attribStack =
indexStack =
if str(attr.dataType()) == “attribData.Float”:
listPAttrib = myGeo.pointFloatAttribValues(attr.name())
pAttribSize = attr.size()
vindx = 0
for v in vertIndex:
for indx in range(pAttribSize):
attribStack.append(listPAttrib)
indexStack.append(vertIndex)
print (time.clock()-startb)

kni8_2k
HDK extension of HOM ?

http://www.sidefx.com/docs/houdini12.1/hom/extendingwithcpp [sidefx.com]

skk.

btw: you may take a look on struct, numpy, array modules for routines converting string to float arrays, rearranging or shuffling floats. List.append() isn't quite a demon of fast computing neither.