[Bf-committers] [Bf-blender-cvs]  Compiling issue
joeedh at gmail.com
Sat Jan 23 15:19:16 CET 2010
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
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.
> 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:
>>> this breaks compiling again.
>>> Some unresolved stuff in the linking process.
>>> Am 23.01.2010 12:25, schrieb Joseph Eagar:
>>>> 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
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers