[Bf-committers] [Bf-blender-cvs]  Compiling issue
hairbat at yahoo.com
Sat Jan 23 19:53:56 CET 2010
Apologies for the lack of line breaks in the last email,
I had forgotten that yahoo mail doesn't insert them
automatically. Below is the original message formatted
sanely (I hope).
I feel like I should comment on this....
I originally wrote the mem-pool joeedh is using because
b-mesh performance on windows was *significantly* slowed
down by the amount of small allocations it made. It's
actually much worse than edit-mesh in those regards, and
I wanted to do something a *little* bit more sophisticated
than the editmesh fast calloc functions/callbacks. That
being said, the mem-pool is not particularly clever or
complicated code and it should be remembered that it
was written to solve a very specific problem.
Anyway, if I recall correct it was someone on IRC who
suggested I put it in Blenlib in case someone else might
find it useful. Despite this, I think it's only really
appropriate for a narrow range of applications (edit-mesh
and b-mesh being the obvious choices.) I question the
wisdom of tying it to something like guarded alloc where
it has the potential to have unintended and adverse effects
on the rest of the system.
>This is also something I've had to deal with in the bmesh branch, and
>the code I wrote there should never see the light of day in trunk
>(which motivates me to tackle this now :) ). It's really quite
>horrible what I wrote to deal with vgroups performance problems.
When you mention 'horrible performance problems' associated
with vertex groups I'm curious whether or not you measured
this. Did you do profiling? What did you pinpoint as the
More information about the Bf-committers