[Bf-committers] [Bf-blender-cvs]  Compiling issue
Brecht Van Lommel
brecht at blender.org
Sat Jan 23 14:46:45 CET 2010
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
More information about the Bf-committers