[Bf-committers] [Bf-blender-cvs] [26206] Compiling issue

[Geoffrey Bantle]

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.
>
>Joe

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
biggest bottlenecks?

Cheers,
Geoff