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

[joe]

Somehow I proof read that without catching the grammar mistakes.

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 any*one* has had time to tackle, and I need to for
bmesh.  I'm certainly not going to add anything that's actually enabled
*until* after much testing and developer discussion, this was more of an
effort to get the dialoge started.

Joe

On Sat, Jan 23, 2010 at 3:13 PM, joe <joeedh at gmail.com> wrote:
> 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
>>
>