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

[joe]

The purpose was simple experimentation, since we need to do
*something* and at the time I didn't think people would go for using
jcmalloc.  Vgroups really are a bad source of performance loss, mostly
in debug builds (which we need to be usable but aren't in some cases).
 I was hoping to elicit ideas from other people, and go from there.
Anyway, it was silly of me to ignore the possibility of using
jcmalloc, which we can probably drop in as a replacement for malloc
within guardedalloc itself (and even have compile time options to have
guardedalloc go straight through to jcmalloc).

Joe

On Sat, Jan 23, 2010 at 6:53 AM, Brecht Van Lommel <brecht at blender.org> wrote:
> Hi Joe,
>
> Right, I replied to the wrong mail, I was talking about the
> guardedalloc changes. I understand this is experimental, but I don't
> think some more experimentation will be prove this to be the right
> thing to do. It may well lead to a speedup in simple test cases, but a
> simple use of pooling can lead to much wasted memory and make problems
> worse when running Blender for a while. So it is not clear to me what
> the purpose is here, if this is the start of writing an advanced
> memory allocator then I don't think we should try to do that
> ourselves, and if not then I don't think this can be good enough to
> put in a release.
>
> Brecht.
>
> On Sat, Jan 23, 2010 at 3:19 PM, joe <joeedh at gmail.com> wrote:
>> What are you talking about specifically?  It helps with ghash, because
>> each bucket node was being allocated individually, causing a
>> significant speed problem.  This particular solution was very
>> appropriate; it's why we have the mempool library in the first place.
>>
>> Now, the experimental code I committed (#ifdef'd out) to guardedalloc
>> is different (and was a
>> different commit even).  This particular commit has nothing to do with
>> that.  On that topic, OSX has (or had, anyway) a reputation for having
>> a system allocator almost as slow as windows; linux is the only OS as
>> far as I know (other then the BSDs I guess) that doesn't suffer from
>> this.  So it's hardly simply a windows issue.
>>
>> The overhead we get from guardedalloc isn't all that bad, really.  I
>> wasn't talking about that in the slightest.  What I was talking about
>> was the significant performance loss we get from overusing the system
>> allocator, which has caused significant problems for me and others.  I
>> committed the code #ifdef'd out, so people who need it can play around
>> with it but not cause problems for others.  There's a reason it's
>> *experimental*.
>>
>> Joe
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>