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

[Geoffrey Bantle]

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