[Bf-python] Vector data type

[Campbell Barton]

your point about reducing memory being practically significant is hard 
to prove on a practice level
Some exporters that gather all their data, before output to a file, can 
end up storing a lot of vectors- vert locations, normals and uv coords.
of course these could be made into tuples, but vectors can be 
transformed before wighting so in some cases its useful to keep them as 
vectors.

If its possible to save some memory then why not? - though from what 
your saying we can only realy save 48bits, (remove wrap int and 1 float 
pointer), at the moment the sizeof VectorObject prints as 36. (288 bits 
Im guessing?), so its not much smaller, but when exporters can and do 
sometimes run out of memory for large meshes, I dont see why not  reduce 
the size of pyobjects where possible.

I had some problems exporting scenes with 2 gigs of ram a while ago, and 
upgraded to 4,
The problem was with a leak in Vector arithmetic thats since been fixed, 
I may be unfairly picking on Vectors as the cause of my memory problems.

Gilbert, Joseph T. wrote:
> It's a good point. You have 3 float pointers. 1 of them will be NULL. I
> would take a look first at the practical reduction in size rather than
> in theory from different aspects of size modification. 
>
> I would prefer to keep the struct and removed the int flag, rather than
> use a single pointer and an int flag to control the interals of this
> structure. If the reduction in this area is not practically significant
> I can't see the justification in modifying it.
>
> -----Original Message-----
> From: bf-python-bounces at projects.blender.org
> [mailto:bf-python-bounces at projects.blender.org] On Behalf Of Martin
> Poirier
> Sent: Monday, September 25, 2006 6:29 AM
> To: cbarton at metavr.com; Blender Foundation Python list
> Subject: Re: [Bf-python] Vector data type
>
>
>
> --- Campbell Barton <cbarton at metavr.com> wrote:
>
>   
>> I was just looking and some areas for improvement.
>> and found the vector pytype,
>>
>> typedef struct {
>>     PyObject_VAR_HEAD
>>     struct{
>>         float *py_data;        //python managed
>>         float *blend_data;    //blender managed
>>     }data;
>>     float *vec;                //1D array of data
>> (alias)
>>     int size;
>>     int wrapped;            //is wrapped data?
>>     PyObject *coerced_object;
>> } VectorObject;
>>
>>
>> Looks like  theres 3 areas for  improvement.
>> *vec; points to either *py_data; and *blend_data; 
>> depending on  the 
>> wrapped; state.
>> why not just remove  *py_data; and  *blend_data; and
>> use vec only??
>>
>>     int size;
>>     int wrapped;            //is wrapped data?
>>
>> Could both be shorts? -would save 32bits, seems
>> overkill again, 64 bits 
>> of data- for what is a total of 6 possible states.
>>
>> *coerced_object;
>>
>> - We could have vector math with floats and matrices
>> without this.
>>
>> Anyone object to an attempt to optimize  this struct
>> for size?
>>     
>
> I would object to any modifications that would
> decrease the speed of vector manipulation operations.
> So be sure to check that too. And be sure that you're
> really reducing memory footprint, not just theorically
> doing so.
>
> Martin
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around 
> http://mail.yahoo.com 
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
>   


-- 
Campbell J Barton

133 Hope Street
Geelong West, Victoria 3218 Australia

URL:    http://www.metavr.com
e-mail: cbarton at metavr.com
phone: AU (03) 5229 0241