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

[joe]

To reiterate my position.  I committed this on an experimental basis,
and I originally planned to get some other people to run some tests
and review the code accordingly.  I never, ever, *ever* wanted this
code *as it is now* in a release, or enabled by default.  I'm
certainly open to the idea of trashing my code, which again, was
*experimental*, and playing with plugging in jcmalloc or whatever.

This isn't a problem anyway has had time to tackle, and I need to for
bmesh.  I'm certainly not going add anything that's actually enabled
after much testing and developer discussion, this was more of an
effort to get the dialoge started.

Joe

On Sat, Jan 23, 2010 at 10:53 AM, Geoffrey Bantle <hairbat at yahoo.com> wrote:
> 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
>
>
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>