Quote - ...the biggest problem (IMO) with what we're doing currently (lists-of-lists-of-floats) is the shamefull amount of memory being used.  Note that each 'float' (x, y, z) is itself a PyObject, which is made up of:

int ob_refcnt;                          4 bytes
struct _typeobject *ob_type;    4 bytes for pointer, plus huge amount for the structure itself
double ob_fval;                        8 bytes

...so each float has it's own _typeobject allocated for it (roughly 20 pointers (4 bytes each) to other structures of various size, plus what may be another 2 dozen pointers to function calls), along with the additional 8 bytes for the refcnt and pointer.

Ok, fortunately, I was wrong about the _typeobject being allocated for each instance of a float. It looks like there's only one static _typeobject per Python type (maintained by whatever module implements that type).  So that's just a pointer to the static one (whew).

So the memory issue is not nearly as bad as I suspected, but it's still an extra 16 bytes per vertex (8 extra bytes for the 2nd and 3rd floats), plus however much the extra 'list' structure that holds them is.

I'm currently messing with a 'vector' type .pyd extension to figure out how all that works, but ultimately I want to look at doing a vector-list type as well, along with various functions to work with them.

@ADP,

BTW, I'm not ignoring your various suggestions about arrays and string conversions, etc. - I'm just exploring various options and learning something in the process :).

Cinema4D Plugins (Home of Riptide, Riptide Pro, Undertow, Morph Mill, KyamaSlide and I/Ogre plugins) Poser products Freelance Modelling, Poser Rigging, UV-mapping work for hire.