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

[joe]

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

On Sat, Jan 23, 2010 at 5:46 AM, Brecht Van Lommel <brecht at blender.org> wrote:
> Hi Joe,
>
> I'm trying to understand when using a memory pool for small
> allocations would help here. I doesn't avoid any of the overhead of
> our own guardedalloc code, it just replaces malloc. So it's basically
> expected to be a better malloc, in case the one provided by the system
> doesn't work well? To my knowledge, this is only applicable to
> Windows. Perhaps a better solution would be to link in a library like
> tcmalloc or jemalloc on Windows (like e.g. Google Chrome does), rather
> than trying to do this ourselves. It seems to me this is quite a
> complicated thing to do right, and it's already been done better.
>
> Brecht.
>
> On Sat, Jan 23, 2010 at 1:16 PM, joe <joeedh at gmail.com> wrote:
>> I'll look into it.
>>
>> On Sat, Jan 23, 2010 at 4:02 AM, Thomas Dinges <dingto at gmx.de> wrote:
>>> Hi,
>>> this breaks compiling again.
>>> scons/msvc
>>>
>>> http://www.pasteall.org/10530
>>>
>>> Some unresolved stuff in the linking process.
>>>
>>>
>>>
>>>
>>> Am 23.01.2010 12:25, schrieb Joseph Eagar:
>>>> Revision: 26206
>>>>            http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=26206
>>>> Author:   joeedh
>>>> Date:     2010-01-23 12:25:20 +0100 (Sat, 23 Jan 2010)
>>>>
>>>> Log Message:
>>>> -----------
>>>> Initial results of my profiling of the animation system.
>>>> Basically two simple changes, changes, I pulled in the faster
>>>> ghash in bmesh (which uses mempools for allocation, providing
>>>> a substanstial speedup in some cases, and also I inlined some
>>>> of the functions), and I changed __inline to __forceinline for inlining
>>>> of math functions.
>>>>
>>>> I also removed the timer in the view3d zoom op (ctrl-middlemouse)
>>>> that was making it nonfunctional.  Why was that there?
>>>>
>>> _______________________________________________
>>> Bf-committers mailing list
>>> Bf-committers at blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>