[Bf-committers] Re: [Bf-blender-cvs] CVS
commit: blender/source/blender/python/api2_2x Mesh.h Mesh.c
cbarton at metavr.com
Fri Sep 22 19:46:43 CEST 2006
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).
More information about the Bf-committers