[Bf-committers] Re: [Bf-blender-cvs] CVS commit: blender/source/blender/python/api2_2x Mesh.h Mesh.c

[Campbell Barton]

Im probably just being over paranoid from the days when blender would 
suck up 2gig of ram with exporting 1 scene,
that ended up being a memory leak with Mathutils Vectors.

It just seems overkill to have an int for a value that can only ever be 
-1,0,1 or 2.

We need to be carefull especialy with fine grained data where 1 mesh can 
have 600,000 edges - all the iter values would add up to about 2meg.

Probably a better solution is to evaluate how much memory is waisted and 
weather its worth saving,
have separate iterator types for the data so every edge and face need 
not store a value that may never be used.

Branan Riley wrote:
> Even if it does pad it - which it probably does - the math is still
> being done on 8 bits, which is slower... just use ints.
>
> On 9/22/06, Martin Poirier <theeth at yahoo.com> wrote:
>>
>>
>> --- Branan Riley <branan at gmail.com> wrote:
>>
>> > yeah, it would. But it'll actualy run slower, at
>> > least on an x86 chip.
>> > A modern Pentium (or Core) is optimized for 32-bit
>> > numbers, then
>> > 16-bit, then 8-bit. An 8-bit number which exists
>> > solely in a function
>> > will likely be added to the stack - which isn't
>> > aligned. This will
>> > slow down all stack operations (which includes
>> > variable access, and
>> > function calls - ouch). Not only that, arithmetic
>> > operations are
>> > slower on 8-bit numbers. Just go with an int. The
>> > savings in memory
>> > aren't worth the slowdown.
>>
>> Compilers usually make sure alignement is maintained
>> when possible and when it would make sense to do so on
>> the target architecture. Hence why I asked if it did
>> really reduce memory usage (the compiler might have
>> padded the struct).
>>
>> Martin