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 <bre...@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 <joe...@gmail.com> wrote: >> I'll look into it. >> >> On Sat, Jan 23, 2010 at 4:02 AM, Thomas Dinges <din...@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@blender.org >>> http://lists.blender.org/mailman/listinfo/bf-committers >>> >> _______________________________________________ >> Bf-committers mailing list >> Bf-committers@blender.org >> http://lists.blender.org/mailman/listinfo/bf-committers >> >> > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers